[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Reproduceable Segmentation fault while saving images (#444)

Clément Béra bera.clement at gmail.com
Mon Dec 2 12:14:54 UTC 2019


On Mon, Dec 2, 2019 at 11:44 AM Alistair Grant <akgrant0710 at gmail.com>
wrote:

>
> Hi Nicolas,
>
>
> On Sun, 1 Dec 2019 at 21:10, Nicolas Cellier <notifications at github.com>
> wrote:
> >
> >
> >
> > Very good job! Thanks Alistair for your tenacity and Clement for letting
> us learn the advanced technics.
> > A pity that the snippet did not fail in Squeak...
>
> This was interesting in that before this year I can't remember the
> last time the VM crashed for me (other than my own mistakes while
> working on plugins).  Then this year it has got to the point where it
> is significantly impacting our productivity.  I guess it is something
> about the size of the images we're using that just happens to line up
> with the trigger conditions.
>
> Yeah that bug would happen only when the compactor would decide to go for
a multiple passes compaction, which typically means
Eden size is far smaller than old space size (Eden memory is usually used
to hold first field of moved objects in the compactor).

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
(Maybe loading multiple times the NetBeans bench) and see how it holds the
workload. There's a lot of GC tuning
to do for such heaps. Right now the VM is tuned by default for heaps <
100Mb. See [1] for tips on GC tuning.
I need to set-up the compilation environment for my desktop machine anyway
hoping the C compiler will benefit from
having more threads and more RAM to work with to lower compilation time.

Saving and reloading multi-Gbs heap is also not very good because the VM at
start-up merges old space into a single
memory segment. It would be better to reshape the heaps in different
segments. We tried with Sophie a few years ago but
it's not that easy. If you want to give it a try...

[1]
https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/

Anyway, once Juraj had made it reproducible it was worthwhile
> committing 100% to fixing it.
>
> Thanks for testing it on Squeak, that's something I had on my ToDo
> list, so it saved me some time.
>
> Cheers,
> Alistair
>


-- 
Clément Béra
https://clementbera.github.io/
https://clementbera.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20191202/606d3c04/attachment.html>


More information about the Vm-dev mailing list