G1GC/ JIT compilation bug hunt.

[Vladimir Kozlov]

Dawid,

It is with high probability Compiler problem.

G1 has larger write-barrier code then other GCs. It can affect inlining decisions. You can try to change 
-XX:InlineSmallCode=1000 value. It controls inlining of methods which were already compiled.

You can also try -Xbatch -XX:CICompilerCount=1 to get serial compilations.

Vladimir

On 8/15/13 11:31 AM, Dawid Weiss wrote:
> 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