G1GC/ JIT compilation bug hunt.

[Peter B. Kessler]

On 08/15/13 02:44, Dawid Weiss wrote:
> This just has to have something to do with G1GC, inlining, escape
> analysis and c2 optimizations (as if there was anything else :).
>
> Seems like an update to one of the variables is lost (nextSlice method
> in ByteSliceReader). This method is inlined heavily; I checked the
> following, all of which results in no errors.
>
> 1) passed "-XX:-Inline" - no errors
>
> 2) excluded separately "nextSlice" and the "parent" method from
> compilation - no errors
>
> 3) "-XX:-DoEscapeAnalysis" - preventing escape analysis - no errors
>
> 4) added a dummy value flush in ByteSliceReader.nextSlice by modifying:
>
> upto = nextIndex & ByteBlockPool.BYTE_BLOCK_MASK;
>
> to
>
> foo = upto = nextIndex & ByteBlockPool.BYTE_BLOCK_MASK;
>
> where foo is a static field with no other accesses -- no errors.

This is interesting.  "upto" is an int, so it's not like storing its value in foo gives G1GC a root to discover objects that it didn't have before, e.g., if a write-barrier were missing.  This change would seem to let G1GC off the hook.  Except to the extent that using G1GC somehow triggers the bug.  I don't understand enough about your code to guess why.

What happens if you perturb "upto" in other ways.  E.g., by declaring it "volatile" even though this code seems to be single-threaded.  Or by making "upto" private and using accessor methods?

I'm just guessing.

			... peter

> 5) Changing G1GC to any other GC - no errors.
>
> I also dumped the generated assembly for the flush() method. It's huge
> and, sigh, it's sometimes different even for two runs with identical
> options; I'm guessing parallel compilation tasks hit different stats?
> I noticed upto field write gets optimized away for certain loops but
> the entire logic after all the ideal graph optimizations is not clear
> from the assembly dump.
>
> So it's still an open issue.
>
> D.
>
>
> On Wed, Aug 14, 2013 at 2:54 PM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
>> I don't have a debug build but I have hsdis so I can dump the assembly
>> ;) Robert mentioned the code passes with -Xint and -Xbatch so it's
>> probably a dynamic optimization of some sort. I'll do some digging
>> later today, thanks for the hint, Uwe.
>>
>> Dawid