On Fri, Mar 3, 2017 at 2:10 PM, Cyril Ferlicot D. <cyril.ferlicot@gmail.com> wrote:

On 03/03/2017 14:06, Guillaume Larcheveque wrote:
>
>�� For your case:
>�� - Do you care that your application use some more Mb of RAM ?
>
> No, we don't care about that

I agree

>
>�� - Do you care if your application takes a couple extra ms to answer
>�� a request ? (In any case, the full GC takes much more time and also
>�� delays the answer right now)
>
> No, because we are only using seaside and browser to display
> visualisations and�� UI, so we don't care that it answers with extra ms;
> it will not freeze at all the UI

In addition to Guillaume's comment: If it is in ms we do not care but
longer full GC can be problematic some time. Do you have an idea of how
long would be the full GC depending on the Eden size? If it add 500ms it
should not be a problem. If it add 2sec it might be.

I'm sorry I was not clear.��

The scavenges take up to a couple ms and they are done very frequently. They depend on Eden size because Eden is scavenged.

The full GC is done rarely. The full GC does not depend on Eden size but on old space size. With the new compactor, it takes around 500ms for a 500Mb heap. I would assume it takes more time on larger heaps. On 2Gb heaps, I guess it could take 2 seconds. For this problem, we need to implement an incremental GC. An incremental GC splits the full GC task in multiple sub tasks, allowing to have multiple small pauses instead of one big pause. The incremental GC implementation is on the TODO list. Your company is in the Pharo consortium, so if you discuss this problem during one of the consortium member meetings, you may ask to invest consortium money in this direction.

>
> Thank you very much for your experiment Cl��ment and Vincent; this point
> is really important for us :-)
>
> --
> *Guillaume Larcheveque*

>

--
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Pr��vert 01,
59650 Villeneuve d'ascq France