This is the mail archive of the
mailing list for the GCC project.
Re: ivopts vs. garbage collection
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Ian Lance Taylor <iant at golang dot org>, GCC Development <gcc at gcc dot gnu dot org>, Lynn Boger <laboger at linux dot vnet dot ibm dot com>
- Date: Fri, 8 Jan 2016 11:54:21 +0100
- 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>
On Wed, Jan 6, 2016 at 4:26 PM, Jeff Law <email@example.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.
> 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.