Question regarding JVM crashes in GC
Michael Rasmussen
michael.rasmussen at zeroturnaround.com
Thu Apr 6 15:36:27 UTC 2017
On 6 April 2017 at 15:26, Stefan Johansson <stefan.johansson at oracle.com> wrote:
> could you try running with -XX:+UseSerialGC
> -XX:MarkSweepDeadRatio=0 -XX:MarkSweepAlwaysCompactCount=1 and see if you
> run into the same issues with Serial as the other collectors?
With that, it fails on the very first GC:
# Internal Error (genOopClosures.inline.hpp:110), pid=28567, tid=28569
# assert(!_g->to()->is_in_reserved(obj)) failed: Scanning field twice?
With the following stack trace in hs_err (before report_vm_error is called):
V [libjvm.so+0xcd37a6] void FastScanClosure::do_oop_work<unsigned
int>(unsigned int*)+0x1d6
V [libjvm.so+0xcd6fce] void
InstanceRefKlass::oop_oop_iterate_ref_processing<true,
FastScanClosure>(oop, FastScanClosure*)+0x37e
V [libjvm.so+0xcdade7] void InstanceRefKlass::oop_oop_iterate<true,
FastScanClosure>(oop, FastScanClosure*)+0x187
V [libjvm.so+0xcceff2] InstanceRefKlass::oop_oop_iterate_nv(oop,
FastScanClosure*)+0x32
I'm still trying to debug if it's somewhere in our native code that
triggers this, although I don't understand how/if we can touch
something this deep in the GC.
/Michael
More information about the hotspot-dev
mailing list