Re: ivopts vs. garbage collection

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Jan 6, 2016 at 4:26 PM, Jeff Law <law@redhat.com> wrote:
> On 01/06/2016 08:17 AM, Ian Lance Taylor wrote:
>>
>> The bug report https://golang.org/issue/13662 describes a case in
>> which ivopts appears to be breaking garbage collection for the Go
>> compiler.  There is an array allocated in memory, and there is a loop
>> over that array.  The ivopts optimization is taking the only pointer
>> to the array and subtracting 8 from it before entering the loop.
>> There are function calls in between this subtraction and the actual
>> use of the array.  During those function calls, a garbage collection
>> occurs.  Since the only pointer to the array no longer points to the
>> actual memory being used, the array is unexpectedly freed.
>>
>> That all seems clear enough, although I'm not sure how best to fix it.
>> What I'm wondering in particular is whether Java does anything to
>> avoid this kind of problem.  I don't see anything obvious.  Thanks for
>> any pointers.
>
> 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).

Note that a similar issue may occur with a pointer one after the last element
(which is valid in C).  Not sure if your GC handles this case well.

Richard.

> Java doesn't do anything special to the best of my knowledge, it just relies
> on the fact that this kind of situation is very rare.
>
> This is related, but not the same as the issue we have with Ada's virtual
> origins for array accesses where the front-end would set up a similar
> situation, which resulted in a "pointer" that points outside the object.
> When we actually dereference the pointer, it's done so with a base+index
> access which brings the effective address back into the object.  That kind
> of scheme wrecks havoc with segmented targets where the segment selection
> may be from the base register rather than the full effective address.
>
> jeff
>