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