RFC: Code cache scan should use RESOLVE?

Aleksey Shipilev shade at redhat.com
Mon Feb 13 10:15:10 UTC 2017


Yeah.

Disabled:
 http://hg.openjdk.java.net/shenandoah/jdk9/hotspot/rev/71679a736a4d

-Aleksey

On 02/13/2017 11:10 AM, Roman Kennke wrote:
> In fact, I thought about it a little more. Oops in the code cache
> should never point to from-space. When installing a new nmethod, we
> ensure all oops are pointing to to-space. Then, during final-mark
> pause, we evacuate + update all code cache roots. If we hit an assert
> there, something else went very wrong.
> 
> Could you please revert that change? I will investigate the issue.
> 
> Roman
> 
> 
> Am Montag, den 13.02.2017, 09:50 +0100 schrieb Aleksey Shipilev:
>> Hi,
>>
>> Looking through nightly test failures, this caught my eye:
>>
>> #  Internal Error
>> (/opt/jenkins/workspace/jdk9-shenandoah-
>> fastdebug/hotspot/src/share/vm/gc/shenandoah/shenandoahConcurrentMark
>> .inline.hpp:247),
>> pid=16927, tid=16935
>> #  assert(oopDesc::unsafe_equals(obj,
>> ShenandoahBarrierSet::resolve_oop_static(obj))) failed: need to-space 
>> object here
>>
>> V  [libjvm.so+0xa6653a]  report_vm_error(char const*, int, char
>> const*, char
>> const*, ...)+0xea
>> V  [libjvm.so+0x143f2d5]  ShenandoahMarkRefsClosure::do_oop(oop*)+0x1
>> 15
>> V  [libjvm.so+0x11f1862]  nmethod::oops_do(OopClosure*, bool)+0x542
>> V  [libjvm.so+0xd74a89]  CodeBlobToOopClosure::do_code_blob(CodeBlob*
>> )+0x29
>> V  [libjvm.so+0x985523]  CodeCache::blobs_do(CodeBlobClosure*)+0x163
>> V  [libjvm.so+0x148e03f]  SCMConcurrentMarkingTask::work(unsigned
>> int)+0x1df
>> V  [libjvm.so+0x16d9225]  GangWorker::loop()+0xc5
>> V  [libjvm.so+0x1252152]  thread_native_entry(Thread*)+0x112
>>
>> It seems to me that with ShenandoahConcurrentCodeRoots enabled
>> recently, we are
>> hitting this path. And oops coming from code roots may be stale, so
>> we need to
>> RESOLVE them? If so, here's a blind patch:
>>   http://cr.openjdk.java.net/~shade/shenandoah/codecache-roots-assert
>> /webrev.01/
>>
>> I was unable to replicate the failure locally, so this is a shot in
>> the dark.
>>
>> Thanks,
>> -Aleksey
>>



More information about the shenandoah-dev mailing list