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.giulie...@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.giulie...@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.giulie...@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 >>>>> >>>>> >>> >>> > >
