jdk8u backport is brokent in 1.8.0.232.b09

[Roman Kennke]

Hi Alexey,

first of all, thank you for reporting and digging so deep! See comments
inline:

> Hello, Shenandoah devs.
> I updated jdk8 from 191-b12 to 232-b09 and started to get spurious freezes
> of my application during startup which occur pretty consistently. Digging
> into gave me impression that is something wrong with java itself. Having
> tried to use fastdebug build I started to get these hs_err.logs:
> https://gist.github.com/genuss/e1969c081f7656ea14e992d84dc8a180

This is a C2 problem, probably caused by Shenandoah's barriers. Since we
changed to a wholly different barrier model, it's not clear whether or
not this problem persists. Probably not. We need to see if it happens
again with current shenandoah/jdk8.

> https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd

This looks like an issue related to JVMTI, and may or may not be
Shenandoah specific. We fixed an issue with JVMTI root scanning, but
this stacktrace doesn't look obviously related. We should look into it.

> and another possible outcome is same as earlier - hung jvm which heavily
> consumes CPU in GC threads with a stacktrace like that (got it with perf):
> 32.32%  libjvm.so     [.] ShenandoahAsserts::assert_correct
> 16.16%  libjvm.so     [.] ShenandoahBarrierSet::write_barrier
> 10.10%  libjvm.so     [.] JvmtiTagMap::do_weak_oops
> 8.43%  libjvm.so      [.] ShenandoahForwardedIsAliveClosure::do_object_b
> 8.25%  libjvm.so      [.]
> ShenandoahEvacuateUpdateRootsClosure::do_oop_work<oop>
> 6.71%  libjvm.so      [.] ShenandoahHeap::in_collection_set<oop>
> 6.16%  libjvm.so      [.] ShenandoahHeap::is_in
> 5.53%  libjvm.so      [.] Metaspace::contains
> 2.70%  libjvm.so      [.] ShenandoahHeap::heap
> 2.43%  libjvm.so      [.] ShenandoahHeap::kind
> 0.76%  libjvm.so      [.] ShenandoahHeap::heap_no_check
> 0.24%  [kernel]       [k] trigger_load_balance
> 0.14%  [kernel]       [k] system_call_fastpath

This is most likely fixed already, being the JVMTI root scanning issue.

> Aleksey Shipilev suggested running on latest shenandoah-backport. I did it
> and it gave me another error in 100% cases (probably unrelated to original
> error). The log is here
> https://gist.github.com/genuss/10eae7f6cc41e9ea1c59ca723915353b
> 

It means that the code buffer for initial code is too small. I am not
sure why this would happen for you, but not for me. However, we should
try this:

https://paste.fedoraproject.org/paste/3Tpm34drmQDqRYUExq~9SA

If you are able to build a JVM with this patch you could try it out
directly, otherwise I'll commit that for testing purposes and you could
pick up one of our nightlies as soon as it appears? It's a little bit
tricky because I can only blindly increase the code_size1 until we have
enough. It may take a few rounds of trying...

Roman