Thanks for the follow up.�� Glad to hear its nothing intrinsic to Pharo. ��

btw, Is there somewhere in the documentation or class/method comments that you believe this N-base situation should be spelled out better?

cheers -ben

On Wed, May 3, 2017 at 8:32 PM, Raffaello Giulietti <raffaello.giulietti@lifeware.ch> wrote:

Problem solved.

The cause was a mismatch between a 0-based index and a 1-based index on copying arrays between Smalltalk and C.

Rather confusingly, for some reason, FFI indices are 1-based even for C arrays, so that calling ExternalAddress>>byteAt:put:, for example, requires the index to be unnaturally 1-based.

While I put a lot of care at this issue, a specific spot in the code was erroneous, leading to an improperly terminated C-style string which, in turn, caused the indirect crash of Pharo.

My fault, however, neither Pharo's nor the JVM's.

Thanks to all involved in replies.

Greetings
Raffaello

On 2017-05-03 13:52, Ben Coman wrote:

On Wed, May 3, 2017 at 4:33 PM, Raffaello Giulietti <raffaello.giulietti@lifeware.ch <mailto:raffaello.giulietti@lifeware.ch>> 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
�� <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>
�� <mailto:dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>>> 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
�� <raffaello.giulietti@lifeware.ch
�� <mailto:raffaello.giulietti@lifeware.ch>
�� <mailto:raffaello.giulietti@lifeware.ch

�� <mailto:raffaello.giulietti@lifeware.ch>>>:

�� 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