<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec 2, 2019 at 11:44 AM Alistair Grant <<a href="mailto:akgrant0710@gmail.com">akgrant0710@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
Hi Nicolas,<br>
<br>
<br>
On Sun, 1 Dec 2019 at 21:10, Nicolas Cellier <<a href="mailto:notifications@github.com" target="_blank">notifications@github.com</a>> wrote:<br>
><br>
><br>
><br>
> Very good job! Thanks Alistair for your tenacity and Clement for letting us learn the advanced technics.<br>
> A pity that the snippet did not fail in Squeak...<br>
<br>
This was interesting in that before this year I can't remember the<br>
last time the VM crashed for me (other than my own mistakes while<br>
working on plugins).  Then this year it has got to the point where it<br>
is significantly impacting our productivity.  I guess it is something<br>
about the size of the images we're using that just happens to line up<br>
with the trigger conditions.<br>
<br></blockquote><div>Yeah that bug would happen only when the compactor would decide to go for a multiple passes compaction, which typically means </div><div>Eden size is far smaller than old space size (Eden memory is usually used to hold first field of moved objects in the compactor).</div><div><br></div><div>My personal desktop has more RAM now that I used to have so I'll try later this week to run the VM on a 100+Gb heap </div><div>(Maybe loading multiple times the NetBeans bench) and see how it holds the workload. There's a lot of GC tuning </div><div>to do for such heaps. Right now the VM is tuned by default for heaps < 100Mb. See [1] for tips on GC tuning.</div><div>I need to set-up the compilation environment for my desktop machine anyway hoping the C compiler will benefit from </div><div>having more threads and more RAM to work with to lower compilation time. </div><div><br></div><div>Saving and reloading multi-Gbs heap is also not very good because the VM at start-up merges old space into a single </div><div>memory segment. It would be better to reshape the heaps in different segments. We tried with Sophie a few years ago but </div><div>it's not that easy. If you want to give it a try...</div><div> </div><div>[1] <a href="https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/">https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Anyway, once Juraj had made it reproducible it was worthwhile<br>
committing 100% to fixing it.<br>
<br>
Thanks for testing it on Squeak, that's something I had on my ToDo<br>
list, so it saved me some time.<br>
<br>
Cheers,<br>
Alistair<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><span style="font-size:12.8px">Clément Béra<br></span><span style="color:rgb(0,0,238)"><a href="https://clementbera.github.io/" target="_blank">https://clementbera.github.io/</a></span><div style="font-size:12.8px"><a href="https://clementbera.wordpress.com/" target="_blank">https://clementbera.wordpress.com/</a></div></div></div></div></div></div></div>