Oct 20 1999.	A Macintosh allocation problem

Until Mac OS-X comes out all mac applications get a fixed partition of memory which is setable as an attribute of the application. (I know, I know, temp memory, but it's not applicable here, or is it? How Mac aware was Visualworks 2.5? NOT!) One day at a client who's mac oriented I got an emergency out of memory dialog. Problem was the VisualWorks VM had lots of memory still available in its partition. Now some further digging showed a problem with the new allocation logic It seemed that under certain conditions I.E. growth over reclamation the logic would ask the Mac OS to give it another chunk of memory, much faster than doing any GC work. Of course the Mac OS can't, which then causes failure. Now instead of doing a GC to find some garbage filled space we die. This of course only happened under some unique circumstances.

The fix of course (if I can find it) was to have the logic attempt other memory reclamation attempts before failing, usually this worked.

(Oct 20th 1999) Ah found the notes:

The MacIntosh environment has unique issues on how memory is used. VisualWorks is not a sophisticated Macintosh application, when memory is allocated it is allocated within the Object Engine application space. This size is set via the 'Get Info' dialog found via the MacIntosh finder. This memory size dictates the total amount of memory dedicated to VisualWorks and is set to an arbitrary limit of 18MB which may or may not be sufficient for Smalltalk application. More sophisticated Macintosh application allocate memory from the System global memory area and become limited by the total amount of memory available on the Macintosh much like Unix or Windows. Optionally Macintosh utilities exist to alter the default memory allocation patterns at a system level and could be investigated as a solution to better mange memory on the Mac.

To compare the Windows NT/95 and Unix implementations of VisualWorks are only limited in their memory usage by either a 512MB ceiling {1999 Note not true today limit is much higher, how high?} enforced by the VW Object engine or the amount of swap space (Virtual Memory) defined to Windows or Unix, usually in the 100 of MB. Since your application now shares desktop space with heavyweight application like Netscape which used as much as 18MB of memory on my test machine you should consider the amount of memory really required for macintosh platforms that run your application. Within the VisualWorks MemoryPolicy logic two problems were encounter that are aggravated by the 18MB memory ceiling which is not seen on Unix or NT. When allocation for a large object, say an Array, is done and fails the recovery code attempts to grow the image. This fails on the Mac. The code then checks for space in OldSpace, there is none, then it checks for space in LargeSpace. In this case it finds sufficient memory in LargeSpace, however the Object Engine cannot allocate the object in LargeSpace and the re-try fails. I believe this code is incorrect, and this problem is only encounter on the Mac. The solution is to change the original PPDT code to only consider OldSpace memory.

When Space is low the LowSpace logic does a Mark/Sweep of OldSpace, then attempts a grow event. If space is not found then an Emergency No Space available notifier is raised. Usually this code is not executed on NT/95 or Unix since the grow request is granted. However on the Mac the grow is denied and we enter the failure code. This logic is incomplete since a Compacting Mark/Sweep should be done and it may recover sufficient memory for the application to continue. The solution is to invoke a Compacting Mark/Sweep GC before giving up. This defers the lowMemory notifier event. In general I found the original logic as supplied by PPDT would given up the search for memory under low memory conditions too early on the MacIntosh and sometimes not grow memory correctly. The suggested changes ensure when the Object Engine gives up there is fact is the maximum amount of memory allocated and consumed on the Macintosh.

PS another change Code Cache to 3x

The Object Engine translates ByteCodes to platform specific instructions on the fly. Methods that get translated are then cached and reused. On Unix based RISC platform the default size for the cache is 1MB. Historically values for Intel and Motorola 68K machines were about 640K since complex CPU instruction set CPUs require fewer instructions per method. When the PowerPC version of the Object Engine was built by PPDT they failed to change the default PowerPC cache size to 1MB and left it at 640K. Changing the size to roughly 2MB has a noticeable effect on the MacIntosh version of the Object Engine.