Re: 回复: 回复: 回复: JVM crashes constantly when High GC happens

[shang xinli]

Thanks Andrew and Thomas!

Sent from my iPhone

> On Apr 25, 2019, at 12:45 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi,
> 
>> On Wed, 2019-04-24 at 20:01 +0000, shang xinli wrote:
>> Thanks Andrew! 
>> 
>> Can you explain a little bit more why the displayed hdr count
>> implicit memory corruption? I don't quite understand why the lock
>> contention is connected with memory corruption. 
> 
>  that guarentee basically checks that values calculated twice in
> different ways at the end of gc correspond with each other.
> 
> Just by looking at the verification code a bit:
> - once by traversing the objects directly as CMS links the promoted
> (copied) objects together during GC (in the object header) and counting
> the objects that had a lock on them (also stored in that link).
> 
> - once by looking at a data structure (basically a list of arrays) that
> stores all these references to the locks, and counting the number of
> entries. (CMS had to store the original values somewhere because it
> used the header for linking together the promoted objects)
> 
> -----
> 
> This guarantee apparently never failed before, and a search in the
> bugtracker did not show anything either, but CMS has been considered
> "complete" before my time working on Hotspot... :)
> 
> Also a (different) crash happens with G1, which has a completely
> different implementation than CMS - G1 does not link together promoted
> objects during gc.
> 
> The code in question changed last in 2010 - and that has been a move
> into a separate file.
> 
> The crashes only occur when using an external tool.
> 
> Given all this and probably more reasons the most likely (initial)
> area I would look at is the external tool.
> 
> Because of this Andrew also almost immediately said "You do not have a
> bug in the GC". I agree.
> 
> There is no good recipe in tracking down such bugs unfortunately.
> 
> Thanks,
>  Thomas
> 
>