Re: ivopts vs. garbage collection

[Ian Lance Taylor <iant at golang dot org>]

On Mon, Jan 11, 2016 at 10:00 AM, Michael Matz <matz@suse.de> wrote:
>
> On Fri, 8 Jan 2016, Richard Biener wrote:
>
>> > The only solution here is for ivopts to keep a pointer to the array,
>> > not a pointer to some location near, but outside of the array.
>>
>> Yes, the solution is to make IVOPTs not do this (eventually controlled
>> by a parameter because clearly it thinks doing this is beneficial
>> cost-wise).
>
> 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?

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.  Only when a derived pointer
points outside of the object (including just after the end of the
object) is it necessary to explicitly keep a base pointer alive.

It's also not obvious to me that making a pointer transformation into
an optimization barrier would be a win overall.  For something like
ivopts it seems better to simply not introduce the pointer
transformation--to apply ivopts only to non-pointers when GC matters
(GC matters not only for Go and Java, but also for any C/C++ program
using something like the Boehm collector).

(I'm still puzzled by the fact that Java has apparently not
encountered this problem in all these years.)

Ian