RFR (S) 5103339: Strengthen NoSafepointVerifier

Doerr, Martin martin.doerr at sap.com
Tue Aug 6 08:19:58 UTC 2019


Hi Coleen,

sorry, the Shenandoah issue seems to be related to JDK-8229000 which came in yesterday.
So I think this change works fine.

Best regards,
Martin


> -----Original Message-----
> From: Doerr, Martin
> Sent: Dienstag, 6. August 2019 10:03
> To: coleen.phillimore at oracle.com; hotspot-runtime-dev at openjdk.java.net
> runtime <hotspot-runtime-dev at openjdk.java.net>
> Subject: RE: RFR (S) 5103339: Strengthen NoSafepointVerifier
> 
> Hi Coleen,
> 
> I've run your change through our nightly tests and I've seen Shenandoah test
> failures.
> AFAIK neither you nor us support this GC, so somebody familiar with it
> should take a look.
> 
> assert(thread->is_Java_thread() || !do_safepoint_check ||
> _safepoint_check_required != Monitor::_safepoint_check_never) failed:
> NonJavaThread should not check for safepoint
> 
> V  [libjvm.so+0x1380ce4]  Monitor::lock(Thread*)+0x574
> V  [libjvm.so+0x1680f8e]
> ShenandoahRootUpdater::ShenandoahRootUpdater(unsigned int,
> ShenandoahPhaseTimings::Phase, bool)+0x29e
> V  [libjvm.so+0x160713d]
> ShenandoahConcurrentMark::update_roots(ShenandoahPhaseTimings::Pha
> se)+0xfd
> V  [libjvm.so+0x166ead0]
> ShenandoahMarkCompact::phase1_mark_heap()+0x290
> V  [libjvm.so+0x1670285]
> ShenandoahMarkCompact::do_it(GCCause::Cause)+0x205
> V  [libjvm.so+0x1647976]  ShenandoahHeap::op_full(GCCause::Cause)+0x36
> V  [libjvm.so+0x164a37a]
> ShenandoahHeap::entry_full(GCCause::Cause)+0x10a
> 
> Other tests look good.
> 
> Best regards,
> Martin



More information about the hotspot-runtime-dev mailing list