RFR (S) 5103339: Strengthen NoSafepointVerifier

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Tue Aug 6 15:43:12 UTC 2019


Thanks Martin.  I see that it was fixed in shenandoah.  Sorry for the 
breakage.   I'll test out the next one in my patch queue against shenandoah.
Coleen

On 8/6/19 4:19 AM, Doerr, Martin wrote:
> 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