On Wed, May 3, 2017 at 4:33 PM, Raffaello Giulietti < [email protected]> wrote:
> Unfortunately, as I just discovered, older versions of Pharo do not > support UFFI. I don't have the time (nor a real interest) in backporting > the code to an older pre-Spur VM which has probably reached its EOL just > for the sake of experimentation. It would probably take hours to understand > the older FFI model and to adapt the code for no real advantage. > > The current Pharo VM seems to support only the --memory option: I tried > with 1 and 2 GiB, nothing changes in the misbehavior. > > I also tried the two heap-related JVM options in isolation, > unsuccessfully. Just for information, the current values for the options > are -Xms16m and -Xmx512m, meaning that the JVM heap should start with 16 > MiB and grow to a maximum size of 512 MiB, both of which are rather modest > values even for a 32 bit process. Besides, they work in VisualWorks (32 > bit). > What about tiny memory allocation like --memory 100m and -Xmx 100m ? Can you share some code that causes the crash? cheers -ben > > The StackOverflow page indicated below is from year 2010, during the age > of Java 6. The JVM has undergone major changes since then, including memory > management, so I'm not sure the discussion there is relevant for Java 8, > the release we are targeting as of today. But even if it were, I still > cannot understand the crash in Pharo. > > > > > > > > > > On 2017-05-03 06:36, Ben Coman wrote: > >> >> >> On Wed, May 3, 2017 at 12:30 AM, Denis Kudriashov <[email protected] >> <mailto:[email protected]>> wrote: >> >> Could you check how it works with Pharo5 which was based on prespur >> CogVM? >> >> >> Note, Pharo 5 Release was a Spur VM. >> Try using... >> http://files.pharo.org/get-files/50-preSpur/ >> http://files.pharo.org/image/50-preSpur/50495.zip >> >> or even Pharo 4. >> >> cheers -ben >> >> >> 2017-05-02 16:36 GMT+02:00 Raffaello Giulietti >> <[email protected] >> <mailto:[email protected]>>: >> >> >> 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. >> >> >> Can you isolate whether the problem is either one of those, or it happens >> with both, and if there is some cutoff where it works? Also, perhaps try >> limiting heap being used by Pharo >> --memory <size>[mk] use fixed heap size (added to image size) >> --mmap <size>[mk] limit dynamic heap size (default: 1024m) >> [out 2G on 32-bit) >> --maxoldspace <size>[mk] set max size of old space memory to >> bytes >> (disclaimer, I'm not too knowledgeable on these, just pulled them >> from --help) >> >> Also consider that heap needs to be contiguous... >> **http://stackoverflow.com/questions/2457514/understanding- >> max-jvm-heap-size-32bit-vs-64bit >> cheers -ben >> >> >> 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? >> >> Greetings >> Raffaello >> >> >> >> >> > >
