marten wrote:Does Smalltalk really runs during the bad numbers ? Or are other processes cosuming the CPU time ????
wembley wrote:I suspect that you are running into garbage collection. Garbage collection on a 1.5GB image is not going to be fast
Try specifying -mo a bit larger than your steady state image size (for example, 1.6GB: -mo 1600000000) and see if it helps. What you want to do is keep garbage collection from happening by giving the image enough room to allocate all its objects at steady state.
Note that you may need to rebase some of the VAST and Windows DLLs (see the MSDN documentation for EDITBIN) in order to get this much memory).
wembley wrote:It's certainly possible that Windows released a replacement DLL with a different base address -- this could be due to any number of reasons. This may have resulted in Smalltalk having difficulty allocating additional memory and so driving Smalltalk to do GC more often. Of course, this is all just speculation based on very little concrete information.
If my speculation is correct, then you will need to rebase some DLLs to free up sufficient continguous memory for allocation.
wembley wrote:The following is a simplified discussion that overlooks some of the subtleties of memory allocation on Windows, but is sufficiently correct for our purposes.
DLLs are typically loaded from low memory to high memory while heap space is allocated from high memory to low memory. However, DLLs can have a load address specified when they are linked and they will be loaded at that address if it isn't already allocated.
As heap space is being allocated, the allocation address will eventually bump into a DLL -- oops, no more memory! But there may be memory holes between DLLs which could be used to satisfy the allocation IF they were continguous with the rest of the free memory.
So, the trick is to use a tool like ProcessExplorer (download from Microsoft) to see the layout of DLLs in memory. Then use EDITBIN (download from Microsoft) to pack the DLL space by moving the "rogue" DLLs to lower memory.
The "rogue" DLLs can be Windows, VAST, or other program's DLLs. With VA Smalltalk 7.5.1 we linked many (but not all) of our DLLs so they occupy contiguous memory. With VA Smalltalk 7.5.2 all the VA Smalltalk DLLs will be packed together to maximize available heap space.
Users browsing this forum: Yahoo [Bot] and 1 guest