- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

by 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. TIA Phil On Wed, May 3, 2017 at 2:32 PM, Raffaello Giulietti <raffaello.giulietti(a)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(a)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(a)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(a)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-…> >> 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 >> >> >> >> >> >> >> > >

May 3, 2017

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

by Raffaello Giulietti

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

May 3, 2017

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

by Ben Coman

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(a)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(a)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(a)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(a)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 >> >> >> >> >> >> >> >> > >

May 3, 2017

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

by Raffaello Giulietti

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(a)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(a)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(a)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-…> > 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 > > > > > > >

May 3, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60480 Home: https://github.com/pharo-project/pharo-core

May 3, 2017

[pharo-project/pharo-core] 74e843: 60480

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 74e84370bac8c84a7f4bc821b2d5c6e506235c63 https://github.com/pharo-project/pharo-core/commit/74e84370bac8c84a7f4bc821… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-05-03 (Wed, 03 May 2017) Changed paths: M HelpSystem-Core.package/CustomHelp.class/class/formatting/url_.st M Pharo-Help.package/WelcomeHelp.class/class/pages/changeLog.st A Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/basic-colors-diffs/diffAdditionalLineBackgroundColor.st A Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/basic-colors-diffs/diffEdgeColor.st A Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/basic-colors-diffs/diffModificatedLineBackgroundColor.st A Polymorph-Widgets.package/Pharo3DarkTheme.class/instance/basic-colors-diffs/diffRemovedLinesBackgroundColor.st A Polymorph-Widgets.package/UIThemeWatery.class/instance/basic-colors-diffs/diffAdditionalLineBackgroundColor.st A Polymorph-Widgets.package/UIThemeWatery.class/instance/basic-colors-diffs/diffAdditionalTextInLineBackgroundColor.st A Polymorph-Widgets.package/UIThemeWatery.class/instance/basic-colors-diffs/diffEdgeColor.st A Polymorph-Widgets.package/UIThemeWatery.class/instance/basic-colors-diffs/diffJoinColor.st A Polymorph-Widgets.package/UIThemeWatery.class/instance/basic-colors-diffs/diffMapColor.st A Polymorph-Widgets.package/UIThemeWatery.class/instance/basic-colors-diffs/diffModificatedLineBackgroundColor.st A Polymorph-Widgets.package/UIThemeWatery.class/instance/basic-colors-diffs/diffRemovalHighlightColor.st A Polymorph-Widgets.package/UIThemeWatery.class/instance/basic-colors-diffs/diffRemovedLinesBackgroundColor.st M STON-Core.package/STONReader.class/instance/private/isSimpleSymbolChar_.st A STON-Tests.package/STONReaderTests.class/instance/tests/testWideSymbol.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60479.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60480.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60479.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60480.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Shout.package/SHTextStylerST80.class/class/styles/darkStyleTable.st M Tool-Diff.package/DiffMapMorph.class/instance/accessing/adoptPaneColor_.st M Tool-Diff.package/DiffMapMorph.class/instance/accessing/defaultColor.st M Tool-Diff.package/DiffMorph.class/instance/accessing colors/additionColor.st A Tool-Diff.package/DiffMorph.class/instance/accessing colors/additionHighlightColor.st A Tool-Diff.package/DiffMorph.class/instance/accessing colors/diffMapColor.st M Tool-Diff.package/DiffMorph.class/instance/accessing colors/edgeColor.st M Tool-Diff.package/DiffMorph.class/instance/accessing colors/joinColor.st M Tool-Diff.package/DiffMorph.class/instance/accessing colors/modificationColor.st M Tool-Diff.package/DiffMorph.class/instance/accessing colors/removalColor.st A Tool-Diff.package/DiffMorph.class/instance/accessing colors/removalHighlightColor.st R Tool-Diff.package/DiffMorph.class/instance/accessing colors/textSelectionColor.st M Tool-Diff.package/DiffMorph.class/instance/instance-creation/newJoinSection.st M Tool-Diff.package/JoinSection.class/README.md M Tool-Diff.package/JoinSection.class/definition.st A Tool-Diff.package/JoinSection.class/instance/accessing/additionHighlightColor.st A Tool-Diff.package/JoinSection.class/instance/accessing/additionHighlightColor_.st A Tool-Diff.package/JoinSection.class/instance/accessing/removalHighlightColor.st A Tool-Diff.package/JoinSection.class/instance/accessing/removalHighlightColor_.st A Tool-Diff.package/JoinSection.class/instance/adding/addHighlightsFrom_to_to_color_.st R Tool-Diff.package/JoinSection.class/instance/as yet unclassified/addHighlightsFrom_to_to_color_.st R Tool-Diff.package/JoinSection.class/instance/as yet unclassified/containsPoint_.st M Tool-Diff.package/JoinSection.class/instance/as yet unclassified/createHighlightsFrom_to_.st R Tool-Diff.package/JoinSection.class/instance/as yet unclassified/drawOn_.st R Tool-Diff.package/JoinSection.class/instance/as yet unclassified/newHighlight.st A Tool-Diff.package/JoinSection.class/instance/drawing/drawOn_.st A Tool-Diff.package/JoinSection.class/instance/instance creation/newHighlight.st A Tool-Diff.package/JoinSection.class/instance/testing/containsPoint_.st Log Message: ----------- 60480 19986 STON do not support WideSymbols https://pharo.fogbugz.com/f/cases/19986 20013 WelcomeHelp for Pharo 6 https://pharo.fogbugz.com/f/cases/20013 19979 Revert gray comments color and fix colors in DiffMorph https://pharo.fogbugz.com/f/cases/19979 http://files.pharo.org/image/60/60480.zip

May 3, 2017

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

by Ben Coman

On Wed, May 3, 2017 at 4:33 PM, Raffaello Giulietti < raffaello.giulietti(a)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(a)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(a)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 >> >> >> >> >> > >

May 3, 2017

Re: [Pharo-dev] PI'm promoting new stable VMs

by Esteban Lorenzano

> On 3 May 2017, at 12:38, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Esteban, > > $ curl http://get.pharo.org/64/60+vmLatest | bash > $ ./pharo --version > > Shows the build version as: > > VM: 201705022326 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > Date: Tue May 2 16:26:41 2017 -0700 $ > > Does that mean we should be building from the opensmalltalk repository > instead of the pharo-vm repository (even temporarily)? officials VM for Pharo now are built using opensmalltalk-vm, yes. we still keep our process for CI/testing purposes, though. Esteban > > Thanks, > Alistair > > > On 3 May 2017 at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> in 15min, I will promote latest VM to stable VM. >> The new stable VM has a lot of bugfixes, notably: >> >> - compactor works >> - Cairo and Surface plugin now can coexist (and it does not crashes) >> - lot of other small things >> >> cheers, >> Esteban >> >

May 3, 2017

Re: [Pharo-dev] PI'm promoting new stable VMs

by Alistair Grant

Hi Esteban, $ curl http://get.pharo.org/64/60+vmLatest | bash $ ./pharo --version Shows the build version as: VM: 201705022326 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Tue May 2 16:26:41 2017 -0700 $ Does that mean we should be building from the opensmalltalk repository instead of the pharo-vm repository (even temporarily)? Thanks, Alistair On 3 May 2017 at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > in 15min, I will promote latest VM to stable VM. > The new stable VM has a lot of bugfixes, notably: > > - compactor works > - Cairo and Surface plugin now can coexist (and it does not crashes) > - lot of other small things > > cheers, > Esteban >

May 3, 2017

Re: [Pharo-dev] Pharo 6 crash when requesting memory from the JVM library

by Esteban Lorenzano

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(a)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(a)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(a)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(a)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 >>>>>>> >>>>>>> >>>>> >>>>> >>> >>> > >

May 3, 2017