How could I load that JVM bridge? I am having a use case or two for that and was thinking that this was not working with new Pharos.
TIA Phil On Wed, May 3, 2017 at 2:32 PM, Raffaello Giulietti <raffaello.giulie...@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.giulie...@lifeware.ch <mailto:raffaello.giulie...@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 >> <dionisi...@gmail.com <mailto:dionisi...@gmail.com> >> <mailto:dionisi...@gmail.com <mailto:dionisi...@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.giulie...@lifeware.ch >> <mailto:raffaello.giulie...@lifeware.ch> >> <mailto:raffaello.giulie...@lifeware.ch >> <mailto:raffaello.giulie...@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 >> >> >> >> >> >> >> > >
