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

Thomas Schatzl thomas.schatzl at oracle.com
Thu Apr 25 07:45:21 UTC 2019


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





More information about the hotspot-gc-dev mailing list