RFR: Evacuate thread stack code oops

[Roman Kennke]

I am not sure I understand. I thought we want to evac them concurrently?
Now you're moving them back to evacuating code roots at STW?

The thread stack code roots are oops in nmethods of methods currently on
the stack, i.e. a subset of all code roots.

Do we understand why it's crashing there?
Why do we have to evac thread stack code roots at stw, but the others
concurrently? By the time we evac the others, they could have become on
stack too?

Roman

Am 30.06.2017 um 21:37 schrieb Aleksey Shipilev:
> I have seen crashes in here:
>
> V  [libjvm.so+0xc9b5a4]  SCMUpdateRefsClosure::do_oop(oopDesc**)+0x74
> V  [libjvm.so+0xb05324]  nmethod::oops_do(OopClosure*, bool)+0x224
> V  [libjvm.so+0x83813f]  CodeBlobToOopClosure::do_code_blob(CodeBlob*)+0x2f
> V  [libjvm.so+0xd5adbe]  JavaThread::oops_do(OopClosure*, CodeBlobClosure*)+0x1ce
> V  [libjvm.so+0xd5fe87]  Threads::possibly_parallel_oops_do(bool, OopClosure*,
> CodeBlobClosure*, CodeBlobClosure*)+0x57
> V  [libjvm.so+0xcad10c]
> ShenandoahRootProcessor::process_java_roots(OopClosure*, CLDClosure*,
> CLDClosure*, CodeBlobClosure*, CodeBlobClosure*, unsigned int)+0xdc
>
> There is a closure for walking thread stack code roots in
> Threads::possibly_parallel_oops_do, but our evacuator passes NULL there. I think
> it should pass our usual code roots closure. For concurrent code cache scan, we
> want to evac those during STW while threads are not moving.
>
> See:
>
> http://cr.openjdk.java.net/~shade/shenandoah/codecache-conc-evac-threadroots/webrev.01
>
> Testing: hotspot_gc_shenandoah
>
> Thanks,
> -Aleksey
>