jdk8u backport is brokent in 1.8.0.232.b09

[Алексей Генус]

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> 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> 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>> 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
> >     >
> >
>
>