G1GC/ JIT compilation bug hunt.
dawid.weiss at gmail.com
Thu Aug 15 11:31:13 PDT 2013
Yeah, I don't understand it either. An assembly dump shows code
differences though -- perhaps it's a side effect of something... don't
know, still digging, time permitting. I'll let you know if I can
figure out something more useful.
On Thu, Aug 15, 2013 at 8:16 PM, Peter B. Kessler
<Peter.B.Kessler at oracle.com> wrote:
> 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;
>> 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.
>> On Wed, Aug 14, 2013 at 2:54 PM, Dawid Weiss <dawid.weiss at gmail.com>
>>> 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.
More information about the hotspot-dev