This is the mail archive of the
mailing list for the GCC project.
Re: ivopts vs. garbage collection
- From: Michael Matz <matz at suse dot de>
- To: Ian Lance Taylor <iant at golang dot org>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Jeff Law <law at redhat dot com>, GCC Development <gcc at gcc dot gnu dot org>, Lynn Boger <laboger at linux dot vnet dot ibm dot com>
- Date: Mon, 11 Jan 2016 20:35:25 +0100 (CET)
- Subject: Re: ivopts vs. garbage collection
- Authentication-results: sourceware.org; auth=none
- References: <CAOyqgcWphMUdS7pMyo9STBChnimJEWm0Ou+wmRtFM2Z500BiJg at mail dot gmail dot com> <568D3217 dot 6050802 at redhat dot com> <CAFiYyc0L0rduOMicug53bxx3-n2DGF-_1D1bEGw4oDWo3wo4vw at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1601111840370 dot 19289 at wotan dot suse dot de> <CAKOQZ8xo5VGos0iy_2SUw9RyPFkqZ4DVO7rNfHkY1PDMpmgm1A at mail dot gmail dot com>
On Mon, 11 Jan 2016, Ian Lance Taylor wrote:
> > Well, that's a hack. A solution is to design something that works
> > generally for garbage collected languages with such requirements
> > instead of arbitrarily limiting transformations here and there. It
> > could be something like the notion of derived pointers, where the base
> > pointer needs to stay alive as long as the derived pointers are. All
> > potential GC points where a derived pointer is alive also needs to
> > have the base pointer be alive (they could explicitely add uses of the
> > base pointers, or alternatively anthing computing liveness needs to
> > deal with this). For normal transformation that don't deal with
> > explicit liveness sets (i.e. most of our SSA transforms) it's enough
> > if the instruction creating the derived pointer from the base can't be
> > looked through, i.e. is an optimization barrier.
> What do you suggest we do for GCC 6?
Realistically? The hack of course.
> Your suggestion of every derived pointer keeping the base pointer alive
> sounds too strong to me; it certainly sounds too strong for Go. For Go
> it should be sufficient to ensure that every derived pointer points
> within the bounds of the object.
Okay, that's a certain type of GC. Others might need exact offset-zero
> It's also not obvious to me that making a pointer transformation into
> an optimization barrier would be a win overall.
It will almost always be a pessimization (the additional live value needs
at least a place on the stack).
> For something like
> ivopts it seems better to simply not introduce the pointer
> transformation--to apply ivopts only to non-pointers when GC matters
Of course that deals only with ivopts. In practice that might be enough,
even for a long time, but it's not really a full solution, there are other
transformations on pointers (e.g. the vectorizer fiddling with alignment),
some of them creating out of object pointers (e.g. chopping off the lowest
Another problem is to define "when GC matters". With LTO you can't rely
on anything from the frontend, so it needs to be encoded in the IL, or at
the very least in a per-function item, with corresponding avoidance of
inlining of GC into non-GC aware functions.
> (I'm still puzzled by the fact that Java has apparently not encountered
> this problem in all these years.)
Probably it just so happened that the base pointer for some derived
pointer was lying around in some memory location. It's not very likely
that the only reference is in a register, it can happen only shortly after
allocating the new block, but before it's actually stored into some other
structure (or freed, i.e. when it's only temporary, but then the base
pointer would be live as well), perhaps this pattern doesn't happen very
often in java code. Obviously it does in Go. Perhaps we can limit the
ivopts hack also to pointers that are problematic. Only if the base
pointer comes from a new allocation (is not loaded from memory) and isn't
stored into memory before use do we need to avoid manipulating it too