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