May 2017 - Pharo-dev - lists.pharo.org

[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

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

by Raffaello Giulietti

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

Re: [Pharo-dev] resizing the windows sometimes blocks the image

by Andrei Chis

Hi, On Wed, May 3, 2017 at 10:43 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hi > > Try resizing the window and clicking inside it a couple times. It usually > refreshes the surface correctly and avoids the need to force quit. > I tried to click a few time but nothing happened. Next time I'll try more :) > > I think it happens to other people too, it seems it's exclusive to Mac OS > X. > Most likely. I didn't had this problem on windows. Cheers, Andrei > Best, > > On Wed, May 3, 2017 at 10:23 AM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> Hi, >> >> With the latest moose image based on Pharo 6 and vm (32 bit) sometimes >> when I resize the main window or enter full screen mode on MacOS the window >> becomes totally white and does not recover:[image: Inline image 1] >> I need to force quit the image. Also this happens not that often and >> quite randomly. >> >> Does this happen to anybody else or it's just me? >> >> Cheers, >> Andrei >> > >

May 3, 2017

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

by Esteban Lorenzano

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

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

by Raffaello Giulietti

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

[pharo-project/pharo-core]

by GitHub

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

May 3, 2017