Smalltalk › Squeak › Squeak VM

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Eliot Miranda-2

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

Hi Alex,, Hi Cyril,

On Tue, Jun 20, 2017 at 10:26 AM, Aliaksei Syrel <[hidden email]> wrote:

Hi Eliot,

I experience the same slowness as Cyril.
Latest Pharo's UI is completely unresponsive and it takes seconds to open new windows, resizing is a nightmare.

Many apologies. I broke the criterion for running global GC when I added the allocation measurement support. The GC is run when the heap is found to have grown by some ration (default 1.5) after each scavenge. When I added the allocation counting support I noticed that there was a bug in the determination of the size of the heap (the old code just looked at the extent of the heap, not the sum of the size of segments) and so I changed it to use the correct size. Evidently I've broken something. I'll fix it asap, but first have some other issues to attend to. It should be fixed before the end of the week.

I made two videos comparing latest and stable VMs. I used 32bit Pharo-60501 on OSX Sierra 10.12.5.

Pharo-VMLatest.mov

Pharo-VMStable.mov

Cheers,
Alex

On 20 June 2017 at 19:14, Eliot Miranda <[hidden email]> wrote:
Hi Cyril,

On Tue, Jun 20, 2017 at 8:08 AM, Cyril Ferlicot <[hidden email]> wrote:
On Tue, Jun 20, 2017 at 5:04 PM, Eliot Miranda <[hidden email]> wrote:
> Hi Clément
>
>
> That was a mistake of mine. In the current VM it now answers e.g. 1011.6 and so things should be working again.
>

Hi!

The problem is that the stable vm does not have the fix and the
current latest vm is **reeeeeeeeally* slow. It happens at least on
OSX.

Can you say more? I'm noticing slow start up on the latest VMs but once it is running I see no issue. What specifically is running slowly for you?

I don't know if it is a known problem or if it comes from the
opensmalltalk build or the pharo build.

I got the VM here: http://files.pharo.org/vm/pharo-spur32/mac/

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

--
_,,,^..^,,,_
best, Eliot

_,,,^..^,,,_

best, Eliot

EstebanLM

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

On 21 Jun 2017, at 23:07, Eliot Miranda <[hidden email]> wrote:

Hi Cyril, Hi Alex,

On Tue, Jun 20, 2017 at 8:08 AM, Cyril Ferlicot <[hidden email]> wrote:
On Tue, Jun 20, 2017 at 5:04 PM, Eliot Miranda <[hidden email]> wrote:
> Hi Clément
>
>
> That was a mistake of mine. In the current VM it now answers e.g. 1011.6 and so things should be working again.
>

Hi!

The problem is that the stable vm does not have the fix and the
current latest vm is **reeeeeeeeally* slow. It happens at least on
OSX. I don't know if it is a known problem or if it comes from the
opensmalltalk build or the pharo build.

I found and fixed the problem just now. See

opensmalltalk-vm/Cog
commit f54456fc05c1846bb7e553c6ff5fec9f700abdae

Author: Eliot Miranda <[hidden email]>
Date: Wed Jun 21 11:17:25 2017 -0700

CogVM source as per VMMaker.oscog-eem.2244

Spur: Fix regression in VMMaker.oscog-eem.2237. sufficientSpaceAfterGC: must
compute heapSizePostGC using totalOldSpaceCapacity instead of the old broken
segment-insensitive endOfMemory - nilObj, otherwise as soon as a segment is
added it's quite possible that there will be a full GC after each scavenge.

So the latest VMs should be back to normal.

yes that should.

I just need to promote them as “stable” :P

Esteban

I got the VM here: http://files.pharo.org/vm/pharo-spur32/mac/

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

--
_,,,^..^,,,_
best, Eliot

Clément Béra

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

On Wed, Jun 21, 2017 at 11:09 PM, Esteban Lorenzano <[hidden email]> wrote:

On 21 Jun 2017, at 23:07, Eliot Miranda <[hidden email]> wrote:

Hi Cyril, Hi Alex,

On Tue, Jun 20, 2017 at 8:08 AM, Cyril Ferlicot <[hidden email]> wrote:
On Tue, Jun 20, 2017 at 5:04 PM, Eliot Miranda <[hidden email]> wrote:
> Hi Clément
>
>
> That was a mistake of mine. In the current VM it now answers e.g. 1011.6 and so things should be working again.
>

Hi!

The problem is that the stable vm does not have the fix and the
current latest vm is **reeeeeeeeally* slow. It happens at least on
OSX. I don't know if it is a known problem or if it comes from the
opensmalltalk build or the pharo build.

I found and fixed the problem just now. See

opensmalltalk-vm/Cog
commit f54456fc05c1846bb7e553c6ff5fec9f700abdae

Author: Eliot Miranda <[hidden email]>
Date: Wed Jun 21 11:17:25 2017 -0700

CogVM source as per VMMaker.oscog-eem.2244

Spur: Fix regression in VMMaker.oscog-eem.2237. sufficientSpaceAfterGC: must
compute heapSizePostGC using totalOldSpaceCapacity instead of the old broken
segment-insensitive endOfMemory - nilObj, otherwise as soon as a segment is
added it's quite possible that there will be a full GC after each scavenge.

So the latest VMs should be back to normal.

yes that should.
I just need to promote them as “stable” :P

Does it also create a new release of Pharo 6 (same image, new VM) ?

Esteban

I got the VM here: http://files.pharo.org/vm/pharo-spur32/mac/

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France

--
_,,,^..^,,,_
best, Eliot