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