On Wed, Jan 6, 2016 at 4:26 PM, Jeff Law <l...@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 >
