On Wed, May 3, 2017 at 4:33 PM, Raffaello Giulietti
<[email protected] <mailto:[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]>
<mailto:[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/get-files/50-preSpur/>
http://files.pharo.org/image/50-preSpur/50495.zip
<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]>
<mailto:[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
<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
