G1GC/ JIT compilation bug hunt.

[Dawid Weiss]

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;
>>
>> 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