Hi Ben,
On May 16, 2017, at 7:42 AM, Ben Coman <btc@openinworld.com> wrote:
On Tue, May 2, 2017 at 10:36 PM, Raffaello Giulietti <raffaello.giulietti@lifeware.ch> wrote:
Hello,
I'm on Pharo 6 (32 bit)/Windows 10 (64 bit).
I'm trying to load and use the (32 bit) JVM DLL into a running Pharo image via the UFFI.
Everything works correctly, including JVM method invocations, except when trying to set the minimum and maximum JVM heap size by passing the -Xms<size> and -Xmx<size> options upon JVM creation. With these options, Pharo simply crashes without leaving any trace.
Apparently, memory management requests from the JVM interfere with Pharo's own memory management.
Please note that we successfully use the same mechanism for both VisualWorks (32 bit)/Windows 10 (64 bit) and Gemstone 64 bit/Linux, so it seems it has to do with a Pharo limitation somehow.
Further, I couldn't find any documentation on how to increase Pharo's working set.
So the questions are: * What is the most probable cause of the crash described above? * Where is there more doc about Pharo's memory configuration settings?
I just bumped into this which you may find interesting... https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/vm... * The upshot of all this is that Squeak will claim (and hold on to) * ALL of the available virtual memory (or at least 75% of it) when * it starts up. If you can't live with that, use the -memory * option to allocate a fixed size heap.
Please be careful to read the code. This is the situation on *non-Spur* VMs (Pharo 5 and earlier, Squeak 4.x and earlier). It is *not* the case on Spur. In Spur on start up the VM allocates enough memory for the heap plus one "growth increment" (currently 16mb) and new space (current default about 5mb on 32 bits, 9mb on 64 bits), and for the native code zone (1mb on x86, about 1.4mb on arm and x64). Spur *does not* reserve address space for the heap. It requests memory for the heap in segments (default 16mb; controllable via a vmParameterAt:put: send). It returns those segments to the is when GC frees segments (the threshold being controllable via a vmParameterAt:put: send).
cheers -ben