[11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming

Mon Mar 23 11:00:28 UTC 2020

Hi Mario,

I think we're all in agreement about stability and ensuring that there are
no performance regressions.

I was thinking that we could adopt the model that you used for the regular
JFR backport to OpenJDK 8 - starting off in a separate repo that can be
built by Adopt and consumed by enthusiasts that want to try it out. Do you
have any concerns about that? It seemed to work very well for that project
- and I would want to use the same sort of caution for Streaming-to-11.

Andrew / Christoph / Severin: What would we need to do to get a separate
repo for Ali Baba / Microsoft / New Relic / AdoptOpenJDK / other interested
parties to investigate in further?

Thanks,

Ben

On Sat, Mar 21, 2020 at 1:52 AM Mario Torre <neugens.limasoftware at gmail.com>
wrote:

> I agree, while this is certainly an interesting feature, we should
> probably let it bake a bit.
>
> I'm particularly concerned about stability and performance here.
>
> Cheers,
> Mario
>
> Il giorno gio 19 mar 2020 alle ore 12:24 Erik Gahlin
> <erik.gahlin at oracle.com> ha scritto:
>
> >
> > Hi,
> >
> > JDK 14 has been out for one day and few have used it in production. The
> > feature changes core aspects of the JFR implementation, such as the
> > tagging mechanism and the parser. Event streaming is not something that
> > can be turned on by an API call or a command line flag, it is always
> > there. If there are bugs, it will likely impact ordinary use of JFR as
> well.
> >
> > Erik
> >
> > > Hi team,
> > >
> > > JDK 14 is now Generally Available, as one of the features, JFR Event
> Streaming is very attractive for us.
> > >
> > > With JFR Event Streaming, we can more easily implement the continuous
> monitoring of Java application based on JFR in the container environment.
> > >
> > > So I would like to backport JDK-8226511(Implement JFR Event Streaming)
> to 11u, please help us to review the patch.
> > >
> > > Previously, we had a discussion at
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-November/002169.html,
> there are many companies interested in this
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8226511
> > > Webrev: http://cr.openjdk.java.net/~ddong/11u-8226511/webrev.00
> > > Test (release/slow-debug on Linux): All JFR Event Streaming passed,
> and other JFR tests have the same result with the build without this patch
> > >
> > > The original patch is large, and cannot be applied to 11u directly
> > > All files that cannot be derectly applied are as follows:
> > >      src/hotspot/share/gc/g1/g1Trace.cpp (dosn't exist in 11u)
> > >      src/hotspot/share/gc/shenandoah/shenandoahJfrSupport.cpp (dosn't
> exist in 11u)
> > >      test/jdk/jdk/jfr/event/metadata/TestLookForUntestedEvents.java
> (dosn't exist in 11u, introduced in JDK-8213914)
> > >      src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java
> > >      src/jdk.jfr/share/classes/jdk/jfr/internal/Repository.java
> > >      src/jdk.jfr/share/conf/jfr/profile.jfc
> > >      src/jdk.jfr/share/conf/jfr/default.jfc
> > >      src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
> > >      src/hotspot/share/jfr/recorder/repository/jfrChunkState.hpp
> > >      src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
> > >      src/hotspot/share/jfr/recorder/repository/jfrRepository.cpp
> > >      src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
> > >      src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp
> > >
> src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
> (ClassLoaderDataGraph_lock doesn't exist in 11u)
> > >      src/hotspot/share/jfr/recorder/checkpoint/types/jfrThreadState.hpp
> > >
> src/hotspot/share/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp
> > >      src/hotspot/share/jfr/recorder/storage/jfrVirtualMemory.cpp
> > >      src/hotspot/share/jfr/utilities/jfrTypes.hpp
> > >      src/hotspot/share/jfr/support/jfrThreadLocal.cpp
> > >      src/hotspot/share/jfr/metadata/metadata.xml
> > >      src/hotspot/share/runtime/mutexLocker.cpp
> > >    test/jdk/ProblemList.txt
> > >
> > > Also, we want to backport some other related issues to 11u:
> > >      JDK-8233700: EventStream not closed
> > >      JDK-8229209: test for cross-process JFR event streaming
> > >      JDK-8234703: [TESTBUG] JFR TestOutOfProcessMigration.java should
> clean up files
> > >      JDK-8234684: JFR crashes when rotating the JFR output during
> assertion failure
> > >      JDK-8233870: JFR TestSetEndTime.java times out - onClose() is
> never called
> > >      JDK-8234888: EventStream::close doesn't abort streaming thread
> > >      JDK-8234671: JFR api/consumer/recordingstream/TestStart.java
> failed due to timeout at testStartTwice()
> > >      JDK-8235356: [TESTBUG] Disable 'producer is alive' check in JFR
> TestCrossProcessStreaming
> > >      JDK-8233111: Epoch shift synchronization point for Compiler
> threads
> > >      JDK-8234059: Stress test fails with "Unexpected Exception in
> thread JFR Event Stream"
> > >      JDK-8236264: Remove jdk.jfr.Recording::setFlushInterval and
> jdk.jfr.Recording::getFlushInterval
> > >      JDK-8236263: Remove experimental streaming events
> > > Most of them can directly apply to 11u, except 8233111, 8234059 and
> 8236263
> > >
> > > Cheers,
> > > Denghui Dong
>
>
>
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/
>