Need help to fix a potential G1 crash in jdk11

Poonam Parhar poonam.bajaj at oracle.com
Mon Jun 8 14:57:09 UTC 2020


Hi Volker,

Did you try running with -XX:+VerifyRememberedSets? This might tell if 
the problem is related to remset updates.

Thanks,
Poonam

On 6/5/20 1:55 AM, Erik Österlund wrote:
> Hi Volker,
>
> On 2020-06-03 20:18, Volker Simonis wrote:
>> Unfortunately, "-XX:-ClassUnloading" doesn't help :(
>
> I am actually happy that did not help. I suspect a bug in that code 
> would be harder to track down; it is rather complicated.
>
>> I already saw two new crashes. The first one has 6 distinct Root 
>> locations pointing to one dead object:
>>
>> [863.222s][info ][gc,verify,start   ] Verifying During GC (Remark after)
>> [863.222s][debug][gc,verify         ] Threads
>> [863.224s][debug][gc,verify         ] Heap
>> [863.224s][debug][gc,verify         ] Roots
>> [863.229s][error][gc,verify         ] Root location 
>> 0x00007f11719174e7 points to dead obj 0x00000000f956dbd8
>> [863.229s][error][gc,verify         ] 
>> org.antlr.v4.runtime.atn.PredictionContextCache
>> [863.229s][error][gc,verify         ] {0x00000000f956dbd8} - klass: 
>> 'org/antlr/v4/runtime/atn/PredictionContextCache'
>> ...
>> [863.229s][error][gc,verify         ] Root location 
>> 0x00007f1171921978 points to dead obj 0x00000000f956dbd8
>> [863.229s][error][gc,verify         ] 
>> org.antlr.v4.runtime.atn.PredictionContextCache
>> [863.229s][error][gc,verify         ] {0x00000000f956dbd8} - klass: 
>> 'org/antlr/v4/runtime/atn/PredictionContextCache'
>> [863.231s][debug][gc,verify         ] HeapRegionSets
>> [863.231s][debug][gc,verify         ] HeapRegions
>> [863.349s][error][gc,verify         ] Heap after failed verification 
>> (kind 0):
>>
>> The second crash has only two Root locations pointing to the same 
>> dead object but more than 40_000 fields in distinct objects pointing 
>> to more than 3_500 dead objects:
>>
>> [854.473s][info ][gc,verify,start   ] Verifying During GC (Remark after)
>> [854.473s][debug][gc,verify         ] Threads
>> [854.475s][debug][gc,verify         ] Heap
>> [854.475s][debug][gc,verify         ] Roots
>> [854.479s][error][gc,verify         ] Root location 
>> 0x00007f6e60461d5f points to dead obj 0x00000000fa874528
>> [854.479s][error][gc,verify         ] 
>> org.antlr.v4.runtime.atn.PredictionContextCache
>> [854.479s][error][gc,verify         ] {0x00000000fa874528} - klass: 
>> 'org/antlr/v4/runtime/atn/PredictionContextCache'
>> [854.479s][error][gc,verify         ] Root location 
>> 0x00007f6e60461d6d points to dead obj 0x00000000fa874528
>> [854.479s][error][gc,verify         ] 
>> org.antlr.v4.runtime.atn.PredictionContextCache
>> [854.479s][error][gc,verify         ] {0x00000000fa874528} - klass: 
>> 'org/antlr/v4/runtime/atn/PredictionContextCache'
>> [854.479s][error][gc,verify         ] Root location 
>> 0x00007f6e60462138 points to dead obj 0x00000000fa874528
>> [854.479s][error][gc,verify         ] 
>> org.antlr.v4.runtime.atn.PredictionContextCache
>> [854.479s][error][gc,verify         ] {0x00000000fa874528} - klass: 
>> 'org/antlr/v4/runtime/atn/PredictionContextCache'
>> [854.482s][debug][gc,verify         ] HeapRegionSets
>> [854.482s][debug][gc,verify         ] HeapRegions
>> [854.484s][error][gc,verify         ] ----------
>> [854.484s][error][gc,verify         ] Field 0x00000000fd363c70 of 
>> live obj 0x00000000fd363c58 in region [0x00000000fd300000, 
>> 0x00000000fd400000)
>> [854.484s][error][gc,verify         ] class name 
>> org.antlr.v4.runtime.atn.ATNConfig
>> [854.484s][error][gc,verify         ] points to dead obj 
>> 0x00000000fa88a540 in region [0x00000000fa800000, 0x00000000fa900000)
>> [854.484s][error][gc,verify         ] class name 
>> org.antlr.v4.runtime.atn.ArrayPredictionContext
>> [854.484s][error][gc,verify         ] ----------
>> ...
>> more than 40_000 fields in distinct objects pointing to more than 
>> 3_500 dead objects.
>>
>> So how can this happen. Is "-XX:+VerifyAfterGC" really reliable here?
>
> Naturally, it's hard to tell for definite what the issue is with only 
> these printouts.
> However, we can make some observations from the printouts:
>
> Based on the address values of the "Root location" of the printouts, 
> each dead object
> reported is pointed at from at least one misaligned oop. The only 
> misaligned oops in
> HotSpot are nmethod oops embedded into the instruction stream as 
> immediates.
> So this smells like some kind of nmethod oop processing bug in G1 to me.
>
> The Abortable Mixed GCs (https://openjdk.java.net/jeps/344) that went 
> into 12 changed
> quite a bit of the nmethod oop scanning code. Perhaps the reason why 
> this stopped
> reproducing in 12 is related to that. The nmethod oop processing code 
> introduced with
> AMGC actually had a word tearing problem for nmethod oops, which was 
> fixed later with
> https://bugs.openjdk.java.net/browse/JDK-8235305
>
> Hope these pointers help.
>
> /Erik
>
>> Thank you and best regards,
>> Volker
>>
>>
>> On Wed, Jun 3, 2020 at 7:14 PM Volker Simonis 
>> <volker.simonis at gmail.com <mailto:volker.simonis at gmail.com>> wrote:
>>
>>     Hi Erik,
>>
>>     thanks a lot for the quick response and the hint with
>>     ClassUnloading. I've just started several runs of the test program
>>     with "-XX:-ClassUnloading". I'll report back instantly once I have
>>     some results.
>>
>>     Best regards,
>>     Volker
>>
>>     On Wed, Jun 3, 2020 at 5:26 PM Erik Österlund
>>     <erik.osterlund at oracle.com <mailto:erik.osterlund at oracle.com>> 
>> wrote:
>>
>>         Hi Volker,
>>
>>         In JDK 12, I changed quite a bit how G1 performs class
>>         unloading, to a
>>         new model.
>>         Since the verification runs just after class unloading, I
>>         guess it could
>>         be interesting
>>         to check if the error happens with -XX:-ClassUnloading as
>>         well. If not,
>>         then perhaps
>>         some of my class unloading changes for G1 in JDK 12 fixed the
>>         problem.
>>
>>         Just a gut feeling...
>>
>>         Thanks,
>>         /Erik
>>
>>         On 2020-06-03 17:02, Volker Simonis wrote:
>>         > Hi,
>>         >
>>         > I would appreciate some help/advice for debugging a
>>         potential G1 crash in
>>         > jdk 11. The crash usually occurs when running a proprietary
>>         jar file for
>>         > about 20-30 minutes and it happens in various parts of the
>>         VM (C1- or
>>         > C2-compiled code, interpreter, GC). Because the crash
>>         locations are so
>>         > different and because the customer which reported the issue
>>         claimed that it
>>         > doesn't happen with Parallel GC, I thought it might be a G1
>>         issue. I
>>         > couldn't reproduce the crash with jdk 12 and 14 (but with
>>         jdk 11 and
>>         > 11.0.7, OpenJDK and Oracle JDK). When looking at the G1
>>         changes in jdk 12 I
>>         > couldn't find any apparent bug fix which potentially solves
>>         this problem
>>         > but it may have been solved by one of the many G1 changes
>>         which happened in
>>         > jdk 12.
>>         >
>>         > I did run the reproducer with "-XX:+UnlockDiagnosticVMOptions
>>         > -XX:+VerifyBeforeGC -XX:+VerifyAfterGC -XX:+VerifyDuringGC
>>         > -XX:+CheckJNICalls -XX:+G1VerifyRSetsDuringFullGC
>>         > -XX:+G1VerifyHeapRegionCodeRoots" and I indeed got
>>         verification errors (see
>>         > [1] for a complete hs_err file). Sometimes it's just a few
>>         fields pointing
>>         > to dead objects:
>>         >
>>         > [1035.782s][error][gc,verify         ] ----------
>>         > [1035.782s][error][gc,verify         ] Field
>>         0x00000000fb509148 of live obj
>>         > 0x00000000fb509130 in region [0x00000000fb500000,
>>         0x00000000fb600000)
>>         > [1035.782s][error][gc,verify         ] class name
>>         > org.antlr.v4.runtime.atn.ATNConfig
>>         > [1035.782s][error][gc,verify         ] points to dead obj
>>         > 0x00000000f9ba39b0 in region [0x00000000f9b00000,
>>         0x00000000f9c00000)
>>         > [1035.782s][error][gc,verify         ] class name
>>         > org.antlr.v4.runtime.atn.SingletonPredictionContext
>>         > [1035.782s][error][gc,verify         ] ----------
>>         > [1035.783s][error][gc,verify         ] Field
>>         0x00000000fb509168 of live obj
>>         > 0x00000000fb509150 in region [0x00000000fb500000,
>>         0x00000000fb600000)
>>         > [1035.783s][error][gc,verify         ] class name
>>         > org.antlr.v4.runtime.atn.ATNConfig
>>         > [1035.783s][error][gc,verify         ] points to dead obj
>>         > 0x00000000f9ba39b0 in region [0x00000000f9b00000,
>>         0x00000000f9c00000)
>>         > [1035.783s][error][gc,verify         ] class name
>>         > org.antlr.v4.runtime.atn.SingletonPredictionContext
>>         > [1035.783s][error][gc,verify         ] ----------
>>         > ...
>>         > [1043.928s][error][gc,verify         ] Heap Regions:
>>         E=young(eden),
>>         > S=young(survivor), O=old, HS=humongous(starts),
>>         HC=humongous(continues),
>>         > CS=collection set, F=free, A=archive, TAMS=top-at-mark-start
>>         (previous,
>>         > next)
>>         > ...
>>         > [1043.929s][error][gc,verify         ] | 
>> 79|0x00000000f9b00000,
>>         > 0x00000000f9bfffe8, 0x00000000f9c00000| 99%| O| |TAMS
>>         0x00000000f9bfffe8,
>>         > 0x00000000f9b00000| Updating
>>         > ...
>>         > [1043.971s][error][gc,verify         ] | 
>> 105|0x00000000fb500000,
>>         > 0x00000000fb54fc08, 0x00000000fb600000| 31%| S|CS|TAMS
>>         0x00000000fb500000,
>>         > 0x00000000fb500000| Complete
>>         >
>>         > but I also got verification errors with more than 30000
>>         fields of distinct
>>         > objects pointing to more than 1000 dead objects. How can
>>         that happen? Is
>>         > the verification always accurate or can this also be a
>>         problem with the
>>         > verification itself and I'm hunting the wrong problem?
>>         >
>>         > Sometimes I also saw verification errors where fields point
>>         to objects in
>>         > regions with "Untracked remset":
>>         >
>>         > [673.762s][error][gc,verify] ----------
>>         > [673.762s][error][gc,verify] Field 0x00000000fca49298 of
>>         live obj
>>         > 0x00000000fca49280 in region [0x00000000fca0000
>>         > 0, 0x00000000fcb00000)
>>         > [673.762s][error][gc,verify] class name
>>         org.antlr.v4.runtime.atn.ATNConfig
>>         > [673.762s][error][gc,verify] points to obj
>>         0x00000000f9d5a9a0 in region
>>         >
>> 81:(F)[0x00000000f9d00000,0x00000000f9d00000,0x00000000f9e00000]
>>         remset
>>         > Untracked
>>         > [673.762s][error][gc,verify] ----------
>>         >
>>         > But they are by far not that common like the pointers to
>>         dead objects. Once
>>         > I even saw a "Root location" pointing to a dead object:
>>         >
>>         > [369.808s][error][gc,verify] Root location
>>         0x00007f35bb33f1f8 points to
>>         > dead obj 0x00000000f87fa200
>>         > [369.808s][error][gc,verify]
>>         org.antlr.v4.runtime.atn.PredictionContextCache
>>         > [369.808s][error][gc,verify] {0x00000000f87fa200} - klass:
>>         > 'org/antlr/v4/runtime/atn/PredictionContextCache'
>>         > [369.850s][error][gc,verify] ----------
>>         > [369.850s][error][gc,verify] Field 0x00000000fbc60900 of
>>         live obj
>>         > 0x00000000fbc608f0 in region [0x00000000fbc00000,
>>         0x00000000fbd00000)
>>         > [369.850s][error][gc,verify] class name
>>         > org.antlr.v4.runtime.atn.ParserATNSimulator
>>         > [369.850s][error][gc,verify] points to dead obj
>>         0x00000000f87fa200 in
>>         > region [0x00000000f8700000, 0x00000000f8800000)
>>         > [369.850s][error][gc,verify] class name
>>         > org.antlr.v4.runtime.atn.PredictionContextCache
>>         > [369.850s][error][gc,verify] ----------
>>         >
>>         > All these verification errors occur after the Remark phase in
>>         > G1ConcurrentMark::remark() at:
>>         >
>>         > verify_during_pause(G1HeapVerifier::G1VerifyRemark,
>>         > VerifyOption_G1UsePrevMarking, "Remark after");
>>         >
>>         > V  [libjvm.so+0x6ca186]  report_vm_error(char const*, int,
>>         char const*,
>>         > char const*, ...)+0x106
>>         > V  [libjvm.so+0x7d4a99]
>>         G1HeapVerifier::verify(VerifyOption)+0x399
>>         > V  [libjvm.so+0xe128bb] Universe::verify(VerifyOption, char
>>         const*)+0x16b
>>         > V  [libjvm.so+0x7d44ee]
>>         >  G1HeapVerifier::verify(G1HeapVerifier::G1VerifyType,
>>         VerifyOption, char
>>         > const*)+0x9e
>>         > V  [libjvm.so+0x7addcf]
>>         >
>>  G1ConcurrentMark::verify_during_pause(G1HeapVerifier::G1VerifyType,
>>         > VerifyOption, char const*)+0x9f
>>         > V  [libjvm.so+0x7b172e] G1ConcurrentMark::remark()+0x3be
>>         > V  [libjvm.so+0xe6a5e1] VM_CGC_Operation::doit()+0x211
>>         > V  [libjvm.so+0xe69908] VM_Operation::evaluate()+0xd8
>>         > V  [libjvm.so+0xe6713f]
>>         VMThread::evaluate_operation(VM_Operation*) [clone
>>         > .constprop.54]+0xff
>>         > V  [libjvm.so+0xe6764e]  VMThread::loop()+0x3be
>>         > V  [libjvm.so+0xe67a7b]  VMThread::run()+0x7b
>>         >
>>         > The GC log output looks as follows:
>>         > ...
>>         > [1035.775s][info ][gc,verify,start   ] Verifying During GC
>>         (Remark after)
>>         > [1035.775s][debug][gc,verify         ] Threads
>>         > [1035.776s][debug][gc,verify         ] Heap
>>         > [1035.776s][debug][gc,verify         ] Roots
>>         > [1035.782s][debug][gc,verify         ] HeapRegionSets
>>         > [1035.782s][debug][gc,verify         ] HeapRegions
>>         > [1035.782s][error][gc,verify         ] ----------
>>         > ...
>>         > A more complete GC log can be found here [2].
>>         >
>>         > For the field 0x00000000fb509148 of live obj
>>         0x00000000fb509130 which
>>         > points to the dead object 0x00000000f9ba39b0 I get the 
>> following
>>         > information if I inspect them with clhsdb:
>>         >
>>         > hsdb> inspect 0x00000000fb509130
>>         > instance of Oop for org/antlr/v4/runtime/atn/ATNConfig @
>>         0x00000000fb509130
>>         > @ 0x00000000fb509130 (size = 32)
>>         > _mark: 13
>>         > _metadata._compressed_klass: InstanceKlass for
>>         > org/antlr/v4/runtime/atn/ATNConfig
>>         > state: Oop for org/antlr/v4/runtime/atn/BasicState @
>>         0x00000000f83ecfa8 Oop
>>         > for org/antlr/v4/runtime/atn/BasicState @ 0x00000000f83ecfa8
>>         > alt: 1
>>         > context: Oop for
>>         org/antlr/v4/runtime/atn/SingletonPredictionContext @
>>         > 0x00000000f9ba39b0 Oop for
>>         > org/antlr/v4/runtime/atn/SingletonPredictionContext @
>>         0x00000000f9ba39b0
>>         > reachesIntoOuterContext: 8
>>         > semanticContext: Oop for
>>         org/antlr/v4/runtime/atn/SemanticContext$Predicate
>>         > @ 0x00000000f83d57c0 Oop for
>>         > org/antlr/v4/runtime/atn/SemanticContext$Predicate @
>>         0x00000000f83d57c0
>>         >
>>         > hsdb> inspect 0x00000000f9ba39b0
>>         > instance of Oop for
>>         org/antlr/v4/runtime/atn/SingletonPredictionContext @
>>         > 0x00000000f9ba39b0 @ 0x00000000f9ba39b0 (size = 32)
>>         > _mark: 41551306041
>>         > _metadata._compressed_klass: InstanceKlass for
>>         > org/antlr/v4/runtime/atn/SingletonPredictionContext
>>         > id: 100635259
>>         > cachedHashCode: 2005943142
>>         > parent: Oop for
>>         org/antlr/v4/runtime/atn/SingletonPredictionContext @
>>         > 0x00000000f9ba01b0 Oop for
>>         > org/antlr/v4/runtime/atn/SingletonPredictionContext @
>>         0x00000000f9ba01b0
>>         > returnState: 18228
>>         >
>>         > I could also reproduce the verification errors with a fast
>>         debug build of
>>         > 11.0.7 which I did run with "-XX:+CheckCompressedOops
>>         -XX:+VerifyOops
>>         > -XX:+G1VerifyCTCleanup -XX:+G1VerifyBitmaps" in addition to
>>         the options
>>         > mentioned before, but unfortunaltey the run didn't trigger
>>         neither an
>>         > assertion nor a different verification error.
>>         >
>>         > So to summarize, my basic questions are:
>>         >   - has somebody else encountered similar crashes?
>>         >   - is someone aware of specific changes in jdk12 which
>>         might solve this
>>         > problem?
>>         >   - are the verification errors I'm seeing accurate or is it
>>         possible to get
>>         > false positives when running with
>>         -XX:Verify{Before,During,After}GC ?
>>         >
>>         > Thanks for your patience,
>>         > Volker
>>         >
>>         > [1]
>>         >
>> http://cr.openjdk.java.net/~simonis/webrevs/2020/jdk11-g1-crash/hs_err_pid28294.log
>>         > [2]
>>         >
>> http://cr.openjdk.java.net/~simonis/webrevs/2020/jdk11-g1-crash/verify-error.log
>>
>



More information about the hotspot-gc-dev mailing list