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

[shang xinli]

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.

Xinli


发送自 Outlook<http://aka.ms/weboutlook>

________________________________
发件人: Andrew Haley <aph at redhat.com>
发送时间: 2019年4月23日 3:15
收件人: shang xinli; Kim Barrett; shade at redhat.com
抄送: hotspot-gc-dev at openjdk.java.net
主题: Re: 回复: 回复: JVM crashes constantly when High GC happens

On 4/19/19 11:08 PM, shang xinli wrote:
> I just reproduced it with the fastdebug build. Now it reports error at PromotionInfo:verify(). More specifically, it found numDisplaceHdrs NOT equal numObjWithDisplaceHdrs. It fails at below.
>
>
> guarantee(numDisplacedHdrs == numObjsWithDisplacedHdrs, "Displaced hdr count”);
>
> Here is the debug info. It would be great if somebody can help to
> guide how to instrument the code to find out the root cause.

There's no recipe that you can use here.

A displaced header occurs when an object is locked, so the object's
first word (with tag bits, etc.) is copied elswhere and replaced in
the object by a pointer to a structure. Displaced headers fairly
uncommon: it only happens when there is contention for a lock and a
thread is blocked. When a GC does its marking phase, it has to keep
track of displaced headers.

You do not have a bug in the GC. The problem is memory corruption. Are
you using any native libraries? That is where I would start.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190424/69135340/attachment.htm>