[11u] [JFR] RFR(XXL) 8226511: Implement JFR Event Streaming
Martijn Verburg
martijnverburg at gmail.com
Tue Mar 24 16:18:54 UTC 2020
Hi all,
Could we create a project/tree/branch for this work (jdk11u-jfr-test or
some such) that a bunch of us could work on together to ensure the
stability and quality of the patch before it goes into 11u?
Cheers,
Martijn
On Mon, 23 Mar 2020 at 11:27, Mario Torre <neugens at redhat.com> wrote:
> 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