Pharo 6 crash when requesting memory from the JVM library
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? Greetings Raffaello
Could you check how it works with Pharo5 which was based on prespur CogVM? 2017-05-02 16:36 GMT+02:00 Raffaello Giulietti < 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.
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
OK, I'll give it a try tomorrow and let the mailing list know about the outcome. On 2017-05-02 18:30, Denis Kudriashov wrote:
Could you check how it works with Pharo5 which was based on prespur CogVM?
2017-05-02 16:36 GMT+02:00 Raffaello Giulietti <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.
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
On Wed, May 3, 2017 at 12:30 AM, Denis Kudriashov <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/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>:
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-3... 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
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). 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>> 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 <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-3... 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
On Wed, May 3, 2017 at 4:33 PM, Raffaello Giulietti < 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>> 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 <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 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
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-3... <http://stackoverflow.com/questions/2457514/understanding-max-jvm-heap-size-3...> 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
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
Hi Ben, On 2017-05-03 14:56, Ben Coman wrote:
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?
Well, I wouldn't call the parameter of ExternalAddress>>byteAt:... methods a "byteOffset", as offset invariably indicates a *difference* between indices or addresses. Thus, I would for example expect an offset of 0 to refer to the first byte, whether its index is 0 or 1. This is in contrast with the Smalltalk convention that <something>At: selectors with numerical arguments usually mean a 1-based *index*. BTW, just for information, what is your role in the development of Pharo? Greetings Raffaello
On Wed, May 3, 2017 at 10:02 PM, Raffaello Giulietti < raffaello.giulietti@lifeware.ch> wrote:
Hi Ben,
On 2017-05-03 14:56, Ben Coman wrote:
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?
Well, I wouldn't call the parameter of ExternalAddress>>byteAt:... methods a "byteOffset", as offset invariably indicates a *difference* between indices or addresses. Thus, I would for example expect an offset of 0 to refer to the first byte, whether its index is 0 or 1.
This is in contrast with the Smalltalk convention that <something>At: selectors with numerical arguments usually mean a 1-based *index*.
BTW, just for information, what is your role in the development of Pharo?
For me Pharo is a dedicated hobby, doing a few hours most week nights and longer stints on weekends. Some people love doing crosswords. I love programming and enjoy Pharo the most. Not having any commercial time pressures has allowed me the luxury to dive deep into areas of interest, which is usually the lower level stuff like DelayScheduler, semaphores/mutexes and Processes in Image & VM - but so far I've not done anything with the JIT. My day job is this... https://www.linkedin.com/in/bencoman/?ppe=1 I dream of one day using Pharo as a soft-realtime industrial automation control system on a Beagleboard, but so far I've taken limited concrete action towards that. I'm located south of the equator in Western Australia, so quite remote from most others in the community (although I did have the pleasure of meeting Thierry & Onil once when they were visiting family here). cheers -ben P.S. I'll take this opportunity to mention I'm between jobs at the moment. So I'd be happy to hear from anyone needing some odd jobs done, while I consider my options.
Hi ben I appreciate your general attitude and I hope that you find the job you love to have. Stef On Thu, May 4, 2017 at 5:59 PM, Ben Coman <btc@openinworld.com> wrote:
On Wed, May 3, 2017 at 10:02 PM, Raffaello Giulietti < raffaello.giulietti@lifeware.ch> wrote:
Hi Ben,
On 2017-05-03 14:56, Ben Coman wrote:
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?
Well, I wouldn't call the parameter of ExternalAddress>>byteAt:... methods a "byteOffset", as offset invariably indicates a *difference* between indices or addresses. Thus, I would for example expect an offset of 0 to refer to the first byte, whether its index is 0 or 1.
This is in contrast with the Smalltalk convention that <something>At: selectors with numerical arguments usually mean a 1-based *index*.
BTW, just for information, what is your role in the development of Pharo?
For me Pharo is a dedicated hobby, doing a few hours most week nights and longer stints on weekends. Some people love doing crosswords. I love programming and enjoy Pharo the most. Not having any commercial time pressures has allowed me the luxury to dive deep into areas of interest, which is usually the lower level stuff like DelayScheduler, semaphores/mutexes and Processes in Image & VM - but so far I've not done anything with the JIT.
My day job is this... https://www.linkedin.com/in/bencoman/?ppe=1 I dream of one day using Pharo as a soft-realtime industrial automation control system on a Beagleboard, but so far I've taken limited concrete action towards that.
I'm located south of the equator in Western Australia, so quite remote from most others in the community (although I did have the pleasure of meeting Thierry & Onil once when they were visiting family here).
cheers -ben
P.S. I'll take this opportunity to mention I'm between jobs at the moment. So I'd be happy to hear from anyone needing some odd jobs done, while I consider my options.
Hi raffael Ben is a contributor of Pharo and he takes care about steady improvement even at the level of comments. Every user of Pharo should have the same take because Pharo is our common wealth. Stef On Wed, May 3, 2017 at 4:02 PM, Raffaello Giulietti < raffaello.giulietti@lifeware.ch> wrote:
Hi Ben,
On 2017-05-03 14:56, Ben Coman wrote:
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?
Well, I wouldn't call the parameter of ExternalAddress>>byteAt:... methods a "byteOffset", as offset invariably indicates a *difference* between indices or addresses. Thus, I would for example expect an offset of 0 to refer to the first byte, whether its index is 0 or 1.
This is in contrast with the Smalltalk convention that <something>At: selectors with numerical arguments usually mean a 1-based *index*.
BTW, just for information, what is your role in the development of Pharo?
Greetings Raffaello
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.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-3...
<http://stackoverflow.com/questions/2457514/understanding-max-jvm-heap-size-3...> 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
Sorry, Phil, this is (currently) not open source software for many reasons. Depending on how Pharo moves in the future, however, we might consider opening it. On 2017-05-03 16:09, phil@highoctane.be wrote:
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.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-3...
<http://stackoverflow.com/questions/2457514/understanding-max-jvm-heap-size-3...> 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
2017-05-03 16:28 GMT+02:00 Raffaello Giulietti < raffaello.giulietti@lifeware.ch>:
Sorry, Phil, this is (currently) not open source software for many reasons. Depending on how Pharo moves in the future, however, we might consider opening it.
So you are not using JNIPort? http://forum.world.st/ANN-JNIPort-for-Pharo-3-0-alpha-td4750750.html.
On 2017-05-03 18:05, Denis Kudriashov wrote:
2017-05-03 16:28 GMT+02:00 Raffaello Giulietti <raffaello.giulietti@lifeware.ch <mailto:raffaello.giulietti@lifeware.ch>>:
Sorry, Phil, this is (currently) not open source software for many reasons. Depending on how Pharo moves in the future, however, we might consider opening it.
So you are not using JNIPort? http://forum.world.st/ANN-JNIPort-for-Pharo-3-0-alpha-td4750750.html.
No, we have our own solution since more than 10 years. JNIPort seems old and it seems Pharo specific. Besides, in addition to Pharo we have to target and to maintain other two quite different environments. We want a similar architecture on all of them.
2017-05-03 16:09 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
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.
I tried load JNIPort today. It is not loaded/working on Pharo6 because it is based on NativeBoost which is not supported by SpurVM. But I created suitable package which resolves missing classes. (in my test repo <http://smalltalkhub.com/#!/~dionisiy/DionisiyPlayground>). It should be loaded before JNI config. This is only thing I did. I not tested anything then
Thanks Denis. On Wed, May 3, 2017 at 6:10 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2017-05-03 16:09 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
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.
I tried load JNIPort today. It is not loaded/working on Pharo6 because it is based on NativeBoost which is not supported by SpurVM. But I created suitable package which resolves missing classes. (in my test repo <http://smalltalkhub.com/#!/~dionisiy/DionisiyPlayground>). It should be loaded before JNI config. This is only thing I did. I not tested anything then
Hi, which vm version are you using? Esteban
On 2 May 2017, at 16:36, 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?
Greetings Raffaello
Hi, how do I discover? I tried with Pharo.exe --version but this shows nothing. Conversely, with PharoConsole here is what I obtain.
C:\pharo6\PharoConsole.exe --version Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
On 2017-05-03 10:36, Esteban Lorenzano wrote:
Hi,
which vm version are you using?
Esteban
On 2 May 2017, at 16:36, 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?
Greetings Raffaello
execute Smalltalk vm version in playground
On 3 May 2017, at 10:47, Raffaello Giulietti <raffaello.giulietti@lifeware.ch> wrote:
Hi,
how do I discover?
I tried with Pharo.exe --version but this shows nothing.
Conversely, with PharoConsole here is what I obtain.
C:\pharo6\PharoConsole.exe --version Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
On 2017-05-03 10:36, Esteban Lorenzano wrote:
Hi, which vm version are you using? Esteban
On 2 May 2017, at 16:36, 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?
Greetings Raffaello
OK, thanks, here it is: CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Seems what PharoConsole outputs, too. On 2017-05-03 10:49, Esteban Lorenzano wrote:
execute
Smalltalk vm version
in playground
On 3 May 2017, at 10:47, Raffaello Giulietti <raffaello.giulietti@lifeware.ch> wrote:
Hi,
how do I discover?
I tried with Pharo.exe --version but this shows nothing.
Conversely, with PharoConsole here is what I obtain.
C:\pharo6\PharoConsole.exe --version Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
On 2017-05-03 10:36, Esteban Lorenzano wrote:
Hi, which vm version are you using? Esteban
On 2 May 2017, at 16:36, 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?
Greetings Raffaello
mmm⦠you can try assigning memory to pharo itself. --memory 1000m (for example) but it may happens that pharo + jvm exceeds the 2g max of a 32bits vm? Esteban
On 3 May 2017, at 10:52, Raffaello Giulietti <raffaello.giulietti@lifeware.ch> wrote:
OK, thanks, here it is:
CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Seems what PharoConsole outputs, too.
On 2017-05-03 10:49, Esteban Lorenzano wrote:
execute Smalltalk vm version in playground
On 3 May 2017, at 10:47, Raffaello Giulietti <raffaello.giulietti@lifeware.ch> wrote:
Hi,
how do I discover?
I tried with Pharo.exe --version but this shows nothing.
Conversely, with PharoConsole here is what I obtain.
C:\pharo6\PharoConsole.exe --version Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
On 2017-05-03 10:36, Esteban Lorenzano wrote:
Hi, which vm version are you using? Esteban
On 2 May 2017, at 16:36, 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?
Greetings Raffaello
No, that does not work, as I reported: On 2017-05-03 10:33, Raffaello Giulietti wrote:
The current Pharo VM seems to support only the --memory option: I tried with 1 and 2 GiB, nothing changes in the misbehavior.
Further, Pharo crashes even when only *starting* with a JVM heap size of 16 MiB, a ridiculously small heap, regardless of the Pharo --memory option and the JVM max heap option. On 2017-05-03 10:55, Esteban Lorenzano wrote:
mmm⦠you can try assigning memory to pharo itself.
--memory 1000m
(for example)
but it may happens that pharo + jvm exceeds the 2g max of a 32bits vm?
Esteban
On 3 May 2017, at 10:52, Raffaello Giulietti <raffaello.giulietti@lifeware.ch> wrote:
OK, thanks, here it is:
CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Seems what PharoConsole outputs, too.
On 2017-05-03 10:49, Esteban Lorenzano wrote:
execute Smalltalk vm version in playground
On 3 May 2017, at 10:47, Raffaello Giulietti <raffaello.giulietti@lifeware.ch> wrote:
Hi,
how do I discover?
I tried with Pharo.exe --version but this shows nothing.
Conversely, with PharoConsole here is what I obtain.
C:\pharo6\PharoConsole.exe --version Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
On 2017-05-03 10:36, Esteban Lorenzano wrote:
Hi, which vm version are you using? Esteban
On 2 May 2017, at 16:36, 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?
Greetings Raffaello
mmm⦠yes. But then⦠it has to be something like that. maybe Eliot can help here. Esteban
On 3 May 2017, at 11:01, Raffaello Giulietti <raffaello.giulietti@lifeware.ch> wrote:
No, that does not work, as I reported:
On 2017-05-03 10:33, Raffaello Giulietti wrote:
The current Pharo VM seems to support only the --memory option: I tried with 1 and 2 GiB, nothing changes in the misbehavior.
Further, Pharo crashes even when only *starting* with a JVM heap size of 16 MiB, a ridiculously small heap, regardless of the Pharo --memory option and the JVM max heap option.
On 2017-05-03 10:55, Esteban Lorenzano wrote:
mmm⦠you can try assigning memory to pharo itself. --memory 1000m (for example) but it may happens that pharo + jvm exceeds the 2g max of a 32bits vm? Esteban
On 3 May 2017, at 10:52, Raffaello Giulietti <raffaello.giulietti@lifeware.ch> wrote:
OK, thanks, here it is:
CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Seems what PharoConsole outputs, too.
On 2017-05-03 10:49, Esteban Lorenzano wrote:
execute Smalltalk vm version in playground
On 3 May 2017, at 10:47, Raffaello Giulietti <raffaello.giulietti@lifeware.ch> wrote:
Hi,
how do I discover?
I tried with Pharo.exe --version but this shows nothing.
Conversely, with PharoConsole here is what I obtain.
C:\pharo6\PharoConsole.exe --version Win32 built on Apr 18 2017 19:55:47 GMT Compiler: 5.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2197 uuid: ef120220-dcf2-4825-ad2c-eab126683414 Apr 18 2017 VM: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 18 12:25:44 2017 -0700 $ Plugins: 201704181925 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
On 2017-05-03 10:36, Esteban Lorenzano wrote:
Hi, which vm version are you using? Esteban
On 2 May 2017, at 16:36, 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?
Greetings Raffaello
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. cheers -ben
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
On Tue, May 16, 2017 at 11:24 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
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.
yes, guilty. I was skimming the code looking at something else and when it caught my eye. I didn't stop to examine it, just drop the link here. Thanks for the correction. cheers -ben
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
participants (7)
-
Ben Coman -
Denis Kudriashov -
Eliot Miranda -
Esteban Lorenzano -
phil＠highoctane.be -
Raffaello Giulietti -
Stephane Ducasse