RFC: Code cache scan should use RESOLVE?

[Roman Kennke]

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
>