[11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
Mario Torre
neugens at redhat.com
Mon Mar 23 11:25:54 UTC 2020
Hi Ben!
Of course I don't have concerns about people trying out things ;)
However regarding having an approach similar to JFR in 8u I'm a bit
more concerned, since the JFR patch had time to bake in and gave us a
chance to fix issues. The streaming API is rather new and changes a
lot of the internal, so we need to give it a bit of time to understand
it.
Personally, I need to study the code and see how having this
implementation may affect backporting of fixes, but my take in general
is that we had to backport JFR because this was a critical missing
feature, but backporting every new feature to 8 or 11 is not
advisable.
I know I said previously that I would have liked to see the streaming
backported, but the level of work required by the JFR backport has
made me change my mind, I think we need to give a chance to JFR in 8u
to be out in the wild for a bit before changing the implementation
again. I'm considering that even if we are talking about 11 here, the
change will most likely apply to 8u as well.
Anyway, this is just my thinking, I'm not trying to veto the change,
we should have a general agreement on what we want to do, if the
maintainers decide this is worth the effort I'll certainly try to help
like I did with the JFR backport.
Cheers,
Mario
On Mon, Mar 23, 2020 at 12:01 PM Ben Evans <bevans at newrelic.com> wrote:
>
> 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/
> >
>
--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
More information about the jdk-updates-dev
mailing list