This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ivopts vs. garbage collection

On 01/06/2016 08:17 AM, Ian Lance Taylor wrote:
The bug report 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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]