[EXTERNAL] Re: Follow up on [JDK-7018422] - JavaAgent code always interpreted during initialization phase
Nhat Nguyen
honguye at microsoft.com
Tue Feb 2 21:46:25 UTC 2021
Hi all,
Thank you all for the thoughtful responses. As someone who's new to the community,
the replies really help me understand the risks involved in such changes; especially it's
jdk8 that we're talking about here. I totally agree and acknowledge that, given the risks,
changing the initialization order for the sake of performance is not plausible enough.
With that said, for completeness sake only, I'm sharing more details on why I thought
that changing the order can help trigger the JIT. But first I acknowledge that my
understanding in this area of the code is limited, and so there are things that I could
have overlooked.
JvmtiExport::post_vm_initialized() [1] calls into eventHandlerVMInit() [2] which runs the
premain method. At this point, CompileBroker::compilation_init() [3] hasn't been called yet,
so the c1 and c2 compiler instances are always null [4]. This in turn makes the JVM deny all
compilation requests [5]. The repro that I used to test the behaviour is [6]. The commands
I used were:
"java -javaagent:target/premain-test-1.0-SNAPSHOT.jar -version" for the premain version
"java -jar target/premain-test-1.0-SNAPSHOT.jar" for the regular main version
In this repro, the premain version is consistently slow as opposed to the main version which
sees significant speedup after the JIT has kicked in. After changing the initialization order, running
the premain version with -XX:+PrintCompilation showed that the JIT is in effect and allowed the
premain version to run as fast as the main one.
As I mention above, I'm sharing the my findings for completeness only. I understand that even if
the JIT is indeed in effect in this particular case, there are certain hidden dependencies that make
this a very risky change.
I'm also cc'ing Trask here, who is more familiar with the javaagent in question, so that he can discuss
some potential workarounds that David mentioned.
Thank you,
Nhat
[1]: JvmtiExport::post_vm_initialized()
https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/91a5bf6cd78c7c073f1e8851217ae3a2241d9441/hotspot/src/share/vm/runtime/thread.cpp#L3638
[2]: eventHandlerVMInit() calling premain
https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/91a5bf6cd78c7c073f1e8851217ae3a2241d9441/jdk/src/share/instrument/InvocationAdapter.c#L490
[3]: CompileBroker::compilation_init()
https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/91a5bf6cd78c7c073f1e8851217ae3a2241d9441/hotspot/src/share/vm/runtime/thread.cpp#L3648
[4]: CompileBroker::compilation_init() initializing c1 & c2 instances
https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/91a5bf6cd78c7c073f1e8851217ae3a2241d9441/hotspot/src/share/vm/compiler/compileBroker.cpp#L897
[5]: https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/91a5bf6cd78c7c073f1e8851217ae3a2241d9441/hotspot/src/share/vm/compiler/compileBroker.cpp#L1350
[6]: https://github.com/trask/premain-test
-----Original Message-----
From: Severin Gehwolf <sgehwolf at redhat.com>
Sent: Thursday, January 28, 2021 2:05 AM
To: David Holmes <david.holmes at oracle.com>; Nhat Nguyen <honguye at microsoft.com>; hotspot-dev at openjdk.java.net
Cc: jdk8u-dev <jdk8u-dev at openjdk.java.net>; Andrew Haley <aph at redhat.com>
Subject: [EXTERNAL] Re: Follow up on [JDK-7018422] - JavaAgent code always interpreted during initialization phase
Hi,
On Thu, 2021-01-28 at 14:37 +1000, David Holmes wrote:
> Hi,
>
> On 28/01/2021 10:51 am, Nhat Nguyen wrote:
> > Hi,
> >
> > I'm writing this email to follow up on JDK-7018422 [1] on jdk8u,
> > where the JavaAgent code is always interpreted during the initialization phase on jdk8.
>
> Just FYI for changes to 8u you need to raise the issue on
> jdk8u-dev at openjdk.java.net.
Adding jdk8u-dev to cc.
>
> > For background, one of our tools is currently making use of a
> > JavaAgent whose performance is important. As part of a performance
> > investigation, I discovered that the CompilerBroker is not
> > initialized by the time the premain method runs, therefore all compilation requests for the JavaAgent are discarded.
> >
> > Fortunately, I found JDK-7018422 which describes the exact issue that we are experiencing.
> > However, the ticket was closed as "Not an issue" because the
> > initialization order is changed with the introduction of the module system.
> >
> > So I would like to ask the mailing list for opinions on whether a
> > fix for this issue can be considered for jdk8u. I have also attached
> > a prototype fix [2] and would appreciate any suggestions and comments as well.
>
> You have to be extremely careful changing the initialization order as
> there are many hidden inter-dependencies.
Yes, and we've been bitten by this before[i]. There is a significant risk involved changing initialization order in stable jdk8u. The reasons given here don't strike me as a good enough reason to accept such a patch. YMMV.
Andrew Haley, thoughts?
Thanks,
Severin
[i] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8249158&data=04%7C01%7Chonguye%40microsoft.com%7C7e9a8beabe6b456f7e8408d8c374348c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637474251920297965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=nXN72pGgJ%2FhFKSPrj4cWfkiblAvhVCug5JcXl1y279I%3D&reserved=0
and https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8233197&data=04%7C01%7Chonguye%40microsoft.com%7C7e9a8beabe6b456f7e8408d8c374348c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637474251920297965%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=OzvFPmEZYa4k2RPGdVYNYc6Du7BH8mOuiB%2FGV666Yeg%3D&reserved=0
> And as Serguei stated, that change may potentially allow JIT'ing to be
> possible, but that doesn't mean it will actually occur.
>
> Cheers,
> David
> -----
>
> >
> > [1]:
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbu
> > gs.openjdk.java.net%2Fbrowse%2FJDK-7018422&data=04%7C01%7Chonguy
> > e%40microsoft.com%7C7e9a8beabe6b456f7e8408d8c374348c%7C72f988bf86f14
> > 1af91ab2d7cd011db47%7C1%7C0%7C637474251920297965%7CUnknown%7CTWFpbGZ
> > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> > %3D%7C2000&sdata=ds5f37k%2B4297QtOCNjd%2BrezIqyU2rmcT4URVBPCB8Kg
> > %3D&reserved=0
> > [2]:
> >
> > ---
> > hotspot/src/share/vm/runtime/thread.cpp | 10 +++++-----
> > 1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/hotspot/src/share/vm/runtime/thread.cpp
> > b/hotspot/src/share/vm/runtime/thread.cpp
> > index 330593acb3..3918f989cc 100644
> > --- a/hotspot/src/share/vm/runtime/thread.cpp
> > +++ b/hotspot/src/share/vm/runtime/thread.cpp
> > @@ -3634,11 +3634,6 @@ jint Threads::create_vm(JavaVMInitArgs*
> > args, bool* canTryAgain) {
> > create_vm_init_libraries();
> > }
> >
> > - // Notify JVMTI agents that VM initialization is complete - nop
> > if no agents.
> > - JvmtiExport::post_vm_initialized();
> > -
> > - JFR_ONLY(Jfr::on_vm_start();)
> > -
> > if (CleanChunkPoolAsync) {
> > Chunk::start_chunk_pool_cleaner_task();
> > }
> > @@ -3648,6 +3643,11 @@ jint Threads::create_vm(JavaVMInitArgs*
> > args, bool* canTryAgain) {
> > CompileBroker::compilation_init();
> > #endif
> >
> > + // Notify JVMTI agents that VM initialization is complete - nop
> > if no agents.
> > + JvmtiExport::post_vm_initialized();
> > +
> > + JFR_ONLY(Jfr::on_vm_start();)
> > +
> > if (EnableInvokeDynamic) {
> > // Pre-initialize some JSR292 core classes to avoid deadlock
> > during class loading.
> > // It is done after compilers are initialized, because
> > otherwise compilations of
> > --
> >
>
More information about the jdk8u-dev
mailing list