jdk8u backport is brokent in 1.8.0.232.b09

[Roman Kennke]

In the meantime, you might want to try again with a recent release build.

Thanks,
Roman


> Roman,
> I uploaded replay file for that very
> run https://gist.github.com/genuss/114201c8658b2f79cc3afaf0d7349648
> Attached file is the class-file which caused error. This is an unusual
> class which was generated by one-nio
> <https://github.com/odnoklassniki/one-nio> in this method
> <https://github.com/odnoklassniki/one-nio/blob/master/src/one/nio/serial/gen/DelegateGenerator.java#L115>.
> 
> 
> On Wed, 13 Nov 2019 at 16:08, Roman Kennke <rkennke at redhat.com
> <mailto:rkennke at redhat.com>> wrote:
> 
>     Hi Alexey,
> 
>     > indeed I didn't  want to use Zero VM - my fault must be misclick
>     when I
>     > downloaded the build.
>     > Just downloaded latest snapshot and tried it out.
>     > 1. Just to be clear I use x86_64, not aarch64. Builds from
>     shipilev.net <http://shipilev.net>
>     > <http://shipilev.net> erroneously say they are aarch64 even for x86_64
>     > builds.
> 
>     Oh, wow. That's bad. We shall fix that then. And I was wondering why we
>     have this surge of aarch64 early adopters.
> 
>     > 2. Freezes indeed are gone. That's already good news.
> 
>     Great!
> 
>     > 3. Error with possible deadlock (from
>     > https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd) still
>     > exists
> 
>     I will look into this right now.
> 
>     > 4. Original C2 issue is gone, nut new one appeared, please
>     > see https://gist.github.com/genuss/51c20a42882cc4026e23ef7ae0ffe69b
> 
>     We might need to see the corresponding replay file (with the same PID as
>     the hs_err file), and ideally the class files/JARs involved in this.
> 
>     Thanks,
>     Roman
> 
>     > Alexey
>     >
>     > On Wed, 13 Nov 2019 at 14:06, Roman Kennke <rkennke at redhat.com
>     <mailto:rkennke at redhat.com>
>     > <mailto:rkennke at redhat.com <mailto:rkennke at redhat.com>>> wrote:
>     >
>     >     I just realized that in your latest test you used a Zero VM.
>     This is
>     >     most likely not what you wanted ;-)
>     >
>     >     Please try:
>     >
>     >     Release build:
>     >   
>      https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-release.tar.xz
>     >
>     >     Fastdebug build:
>     >   
>      https://builds.shipilev.net/openjdk-shenandoah-jdk8/openjdk-shenandoah-jdk8-latest-linux-aarch64-fastdebug.tar.xz
>     >
>     >     Thanks,
>     >     Roman
>     >
>     >
>     >     > 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
>     >     > https://gist.github.com/genuss/310b67fc3f1f49b458c0e13f13b67fdd
>     >     > 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
>     >     >
>     >     > 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
>     >     >
>     >     > Moving back to 1.8.0.192 helps, but maybe we can find the
>     error here.
>     >     > Unfortunately I don't haven a minimal reproducible example, but
>     >     I'm open to
>     >     > any suggestions on how to make it.
>     >     > Do you have any thoughts about how to fix this?
>     >     >
>     >     > Alexey
>     >     >
>     >
>