G1GC/ JIT compilation bug hunt.

[Dawid Weiss]

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.

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