RFC: Code cache scan should use RESOLVE?

[Roman Kennke]

Ooops. Yes, this is correct.

There could be a performance optimization by also updating refs here,
then we wouldn't need to update those refs in the final-mark phase....
but this requires some more thought...


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
>