Re: RFR: 8324582: Replace -Djava.util.concurrent.ForkJoinPool.common.parallelism to -Djdk.virtualThreadScheduler.maxPoolSize in jvmti vthread tests [v4]
> Some jvmti tests use > -Djava.util.concurrent.ForkJoinPool.common.parallelism > to control the pool of virtual threads. However, it is controlled by > jdk.virtualThreadScheduler.parallelism property. > > The non-continuations implementation doesn't use any of these properties and > it was just deleted. > > I verified the fix using jcmd Thread.dump and ran all jvmti tests in the > default configuration. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: reverted copyright update - Changes: - all: https://git.openjdk.org/jdk/pull/17547/files - new: https://git.openjdk.org/jdk/pull/17547/files/0f608fe5..bac51860 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=17547=03 - incr: https://webrevs.openjdk.org/?repo=jdk=17547=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17547.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17547/head:pull/17547 PR: https://git.openjdk.org/jdk/pull/17547
Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v4]
On Wed, 24 Jan 2024 14:48:52 GMT, Volker Simonis wrote:
>> Currently we don't record dependencies on redefined methods (i.e.
>> `evol_method` dependencies) in JIT compiled methods if none of the
>> `can_redefine_classes`, `can_retransform_classes` or
>> `can_generate_breakpoint_events` JVMTI capabalities is set. This means that
>> if a JVMTI agent which requests one of these capabilities is dynamically
>> attached, all the methods which have been JIT compiled until that point,
>> will be marked for deoptimization and flushed from the code cache. For
>> large, warmed-up applications this mean deoptimization and instant
>> recompilation of thousands if not then-thousands of methods, which can lead
>> to dramatic performance/latency drop-downs for several minutes.
>>
>> One could argue that dynamic agent attach is now deprecated anyway (see [JEP
>> 451: Prepare to Disallow the Dynamic Loading of
>> Agents](https://openjdk.org/jeps/451)) and this problem could be solved by
>> making the recording of `evol_method` dependencies dependent on the new
>> `-XX:+EnableDynamicAgentLoading` flag isntead of the concrete JVMTI
>> capabilities (because the presence of the flag indicates that an agent will
>> be loaded eventually).
>>
>> But there a single, however important exception to this rule and that's JFR.
>> JFR is advertised as low overhead profiler which can be enabled in
>> production at any time. However, when JFR is started dynamically (e.g.
>> through JCMD or JMX) it will silently load a HotSpot internl JVMTI agent
>> which requests the `can_retransform_classes` and retransforms some classes.
>> This will inevitably trigger the deoptimization of all compiled methods as
>> described above.
>>
>> I'd therefor like to propose to *always* and unconditionally record
>> `evol_method` dependencies in JIT compiled code by exporting the relevant
>> properties right at startup in `init_globals()`:
>> ```c++
>> jint init_globals() {
>>management_init();
>>JvmtiExport::initialize_oop_storage();
>> +#if INCLUDE_JVMTI
>> + JvmtiExport::set_can_hotswap_or_post_breakpoint(true);
>> + JvmtiExport::set_all_dependencies_are_recorded(true);
>> +#endif
>>
>>
>> My measurements indicate that the overhead of doing so is minimal (around 1%
>> increase of nmethod size) and justifies the benefit. E.g. a Spring Petclinic
>> application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions
>> -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500
>> with C2) resulting in an aggregated nmethod size of around ~40bm.
>> Additionally recording `evol_method` dependencies only increases this size
>> be about 400kb
>
> Volker Simonis has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Made the flag experimental and added an assertion to
> set_can_hotswap_or_post_breakpoint()
Marked as reviewed by dlong (Reviewer).
No, go ahead.
-
PR Review: https://git.openjdk.org/jdk/pull/17509#pullrequestreview-1844939013
PR Comment: https://git.openjdk.org/jdk/pull/17509#issuecomment-1911240540
Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]
On Thu, 25 Jan 2024 13:33:10 GMT, Andrew Dinn wrote: >> Requiring such an API opens the module to anybody, though, punching a hole >> into the module boundary. >> >> BB currently opens the jdk.internal.misc.Unsafe class to a module on a >> seperate class loader that is not reachable outside an agent, using >> Instrumentation. This also caters the need to inject utility classes from an >> agent before any class file transformer is triggered, to maintain a >> well-defined life-cycle. >> >> Of course I'd prefer if there was a way to resolve a lookup from >> Instrumentation for a given class loader and for example a package-info >> class, however rendering the issue that packages might not exist (yet). > >> Requiring such an API opens the module to anybody, though, punching a hole >> into the module boundary. > > How so? Any module created to print Lookups can easily rely on a shared > secret to secure the API. Byteman employs a non-null Instrumentation object > (a value which any agent ought to keep secret). However, it could just as > easily have employed an arbitrary bit length hash key. The key can be used to > initialize a module-private static long[] field of an API implementation > class generated into the module i.e. the hole can actually be a keyhole in > the shape of a key known only to the API client and implementation. Thanks @adinn, @raphw for your feedback. I am not pretending to fully understand what you just explained or to have the slightest clue how to do what you suggested, but reading it for the second time since yesterday seems to make it clearer already. I guess, I cannot hope for a how-to with sample code. But I can immerse myself into the topic some more next time I have a vacant time box and look at Byte Buddy and Byteman source code. - PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1911208017
RFR: JDK-8317636: Improve heap walking API tests to verify correctness of field indexes
The fix adds new test for FollowReferences JVMTI function to verify correctness of reported field indexes. - Commit messages: - jcheck - new test Changes: https://git.openjdk.org/jdk/pull/17580/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17580=00 Issue: https://bugs.openjdk.org/browse/JDK-8317636 Stats: 645 lines in 2 files changed: 645 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17580.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17580/head:pull/17580 PR: https://git.openjdk.org/jdk/pull/17580
Re: RFR: JDK-8324637: [aix] Implement support for reporting swap space in jdk.management
On Thu, 25 Jan 2024 15:33:36 GMT, Matthias Baesken wrote: > > I can't try this and don't use AIX, but it looks good. It follows the same > > pattern as the other AIX cases in the file. > > Although the others (e.g. line 200) don't throw_internal_error if the call > > returns -1, they just return -1. You might want to do that for consistency > > of behaviour. > > Hi I wanted to be consistent to the other OS in > get_total_or_available_swap_space_size, that#s why the throw_internal_error . Ok yes, you can choose who to be consistent with... 8-) - PR Comment: https://git.openjdk.org/jdk/pull/17569#issuecomment-1910585693
Re: RFR: 8324582: Replace -Djava.util.concurrent.ForkJoinPool.common.parallelism to -Djdk.virtualThreadScheduler.maxPoolSize/parallelism in jvmti vthread tests [v3]
On Wed, 24 Jan 2024 21:01:37 GMT, Leonid Mesnik wrote: >> Some jvmti tests use >> -Djava.util.concurrent.ForkJoinPool.common.parallelism >> to control the pool of virtual threads. However, it is controlled by >> jdk.virtualThreadScheduler.parallelism property. >> >> The non-continuations implementation doesn't use any of these properties and >> it was just deleted. >> >> I verified the fix using jcmd Thread.dump and ran all jvmti tests in the >> default configuration. > > Leonid Mesnik has updated the pull request incrementally with one additional > commit since the last revision: > > update copyrights years This looks good but one test may still need an update? test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/VThreadEventTest.java line 210: > 208: > 209: } > 210: Does this test also need an update? It has a line 32: * -Djdk.virtualThreadScheduler.parallelism=9 - Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17547#pullrequestreview-1844041016 PR Review Comment: https://git.openjdk.org/jdk/pull/17547#discussion_r1466558265
Re: RFR: JDK-8324637: [aix] Implement support for reporting swap space in jdk.management
On Thu, 25 Jan 2024 14:25:51 GMT, Thomas Stuefe wrote: > Do we need the cast? perfstat_memory_total_t members are all 64-bit, no? > > Also, can we shorten this to: > > ``` > return (available ? memory_info.pgsp_free : memory_info.pgsp_total) * 4096; > ``` Hi Thomas, I see no types defined here https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface but most likely you are correct and they are 64bit. - PR Review Comment: https://git.openjdk.org/jdk/pull/17569#discussion_r1466552393
Re: RFR: JDK-8324637: [aix] Implement support for reporting swap space in jdk.management
On Thu, 25 Jan 2024 14:11:35 GMT, Kevin Walls wrote: > I can't try this and don't use AIX, but it looks good. It follows the same > pattern as the other AIX cases in the file. > > Although the others (e.g. line 200) don't throw_internal_error if the call > returns -1, they just return -1. You might want to do that for consistency of > behaviour. Hi I wanted to be consistent to the other OS in get_total_or_available_swap_space_size, that#s why the throw_internal_error . - PR Comment: https://git.openjdk.org/jdk/pull/17569#issuecomment-1910449037
Re: RFR: JDK-8324637: [aix] Implement support for reporting swap space in jdk.management
On Thu, 25 Jan 2024 12:30:15 GMT, Matthias Baesken wrote: > The get_total_or_available_swap_space_size coding misses AIX support, we only > return 0. This should be enhanced. > The perfstat API can be used, see > https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface > . Small nit, otherwise good. src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c line 113: > 111: throw_internal_error(env, "perfstat_memory_total failed"); > 112: } > 113: return available ? (jlong)(memory_info.pgsp_free * 4L * 1024L) : > (jlong)(memory_info.pgsp_total * 4L * 1024L); Do we need the cast? perfstat_memory_total_t members are all 64-bit, no? Also, can we shorten this to: return (available ? memory_info.pgsp_free : memory_info.pgsp_total) * 4096; - Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/17569#pullrequestreview-1843868729 PR Review Comment: https://git.openjdk.org/jdk/pull/17569#discussion_r1466454083
Re: RFR: JDK-8324637: [aix] Implement support for reporting swap space in jdk.management
On Thu, 25 Jan 2024 12:30:15 GMT, Matthias Baesken wrote: > The get_total_or_available_swap_space_size coding misses AIX support, we only > return 0. This should be enhanced. > The perfstat API can be used, see > https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface > . I can't try this and don't use AIX, but it looks good. It follows the same pattern as the other AIX cases in the file. Although the others (e.g. line 200) don't throw_internal_error if the call returns -1, they just return -1. You might want to do that for consistency of behaviour. - Marked as reviewed by kevinw (Committer). PR Review: https://git.openjdk.org/jdk/pull/17569#pullrequestreview-1843836792
Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]
On Thu, 25 Jan 2024 12:16:13 GMT, Rafael Winterhalter wrote: > Requiring such an API opens the module to anybody, though, punching a hole > into the module boundary. How so? Any module created to print Lookups can easily rely on a shared secret to secure the API. Byteman employs a non-null Instrumentation object (a value which any agent ought to keep secret). However, it could just as easily have employed an arbitrary bit length hash key. The key can be used to initialize a module-private static long[] field of an API implementation class generated into the module i.e. the hole can actually be a keyhole in the shape of a key known only to the API client and implementation. - PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1910230873
Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v3]
On Tue, 23 Jan 2024 19:57:14 GMT, Vladimir Ivanov wrote: >> Volker Simonis has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Updated option description and assertion based on review feedback > > I support keeping the logic under a flag. I have some concerns about > unconditionally turning it on. > > I expect significantly higher footprint overhead when an application has > plenty of tiny methods and deep inlining trees. And java.lang.invoke > implementation pushes it even further (with arbitrarily deep MethodHandle > trees and unconditional inlining through them), so heavy users of > MethodHandle API should experience higher overheads when evol dependencies > are recorded. > > I suggest to make the flag experimental. Once JFR implementation is improved, > it can be superseded by `-XX:+EnableDynamicAgentLoading` check. @iwanowww , @shipilev , @dean-long any more comments or concerns? Otherwise I'd like to finish this. - PR Comment: https://git.openjdk.org/jdk/pull/17509#issuecomment-1910218698
Re: RFR: 8309271: A way to align already compiled methods with compiler directives [v24]
> Compiler Control (https://openjdk.org/jeps/165) provides method-context > dependent control of the JVM compilers (C1 and C2). The active directive > stack is built from the directive files passed with the > `-XX:CompilerDirectivesFile` diagnostic command-line option and the > Compiler.add_directives diagnostic command. It is also possible to clear all > directives or remove the top from the stack. > > A matching directive will be applied at method compilation time when such > compilation is started. If directives are added or changed, but compilation > does not start, then the state of compiled methods doesn't correspond to the > rules. This is not an error, and it happens in long running applications when > directives are added or removed after compilation of methods that could be > matched. For example, the user decides that C2 compilation needs to be > disabled for some method due to a compiler bug, issues such a directive but > this does not affect the application behavior. In such case, the target > application needs to be restarted, and such an operation can have high costs > and risks. Another goal is testing/debugging compilers. > > It would be convenient to optionally reconcile at least existing matching > nmethods to the current stack of compiler directives (so bypass inlined > methods). > > Natural way to eliminate the discrepancy between the result of compilation > and the broken rule is to discard the compilation result, i.e. > deoptimization. Prior to that we can try to re-compile the method letting > compile broker to perform it taking new directives stack into account. > Re-compilation helps to prevent hot methods from execution in the interpreter. > > A new flag `-r` has beed introduced for some directives related to compile > commands: `Compiler.add_directives`, `Compiler.remove_directives`, > `Compiler.clear_directives`. The default behavior has not changed (no flag). > If the new flag is present, the command scans already compiled methods and > puts methods that have any active non-default matching compiler directives to > re-compilation if possible, otherwise marks them for deoptimization. There is > currently no distinction which directives are found. In particular, this > means that if there are rules for inlining into some method, it will be > refreshed. On the other hand, if there are rules for a method and it was > inlined, top-level methods won't be refreshed, but this can be achieved by > having rules for them. > > In addition, a new diagnostic command `Compiler.replace_directives`, has been > added for ... Dmitry Chuyko has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits: - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - Deopt osr, cleanups - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - Merge branch 'openjdk:master' into compiler-directives-force-update - ... and 32 more: https://git.openjdk.org/jdk/compare/7a798d3c...0c8f11bc - Changes: https://git.openjdk.org/jdk/pull/14111/files Webrev: https://webrevs.openjdk.org/?repo=jdk=14111=23 Stats: 381 lines in 15 files changed: 348 ins; 3 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/14111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14111/head:pull/14111 PR: https://git.openjdk.org/jdk/pull/14111
RFR: JDK-8324637: get_total_or_available_swap_space_size no support on AIX
The get_total_or_available_swap_space_size coding misses AIX support, we only return 0. This should be enhanced. The perfstat API can be used, see https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interface . - Commit messages: - JDK-8324637 Changes: https://git.openjdk.org/jdk/pull/17569/files Webrev: https://webrevs.openjdk.org/?repo=jdk=17569=00 Issue: https://bugs.openjdk.org/browse/JDK-8324637 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17569/head:pull/17569 PR: https://git.openjdk.org/jdk/pull/17569
Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]
On Fri, 16 Apr 2021 20:30:15 GMT, Rafael Winterhalter wrote: >> To allow agents the definition of auxiliary classes, an API is needed to >> allow this. Currently, this is often achieved by using `sun.misc.Unsafe` or >> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed >> from `sun.misc.Unsafe`. > > Rafael Winterhalter has refreshed the contents of this pull request, and > previous commits have been removed. Incremental views are not available. The > pull request now contains one commit: > > 8200559: Java agents doing instrumentation need a means to define auxiliary > classes Requiring such an API opens the module to anybody, though, punching a hole into the module boundary. BB currently opens the jdk.internal.misc.Unsafe class to a module on a seperate class loader that is not reachable outside an agent, using Instrumentation. This also caters the need to inject utility classes from an agent before any class file transformer is triggered, to maintain a well-defined life-cycle. Of course I'd prefer if there was a way to resolve a lookup from Instrumentation for a given class loader and for example a package-info class, however rendering the issue that packages might not exist (yet). - PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1910087337
Re: RFR: JDK-8320005 : Allow loading of shared objects with .a extension on AIX [v9]
On Wed, 24 Jan 2024 07:30:27 GMT, Thomas Stuefe wrote: > For me the unresolved question is still: > > * do we want an unconditional load of *.a for a given *.so (have yet to see > any documentation for this a-file duality) Yes. The documentation link - https://www.ibm.com/docs/en/aix/7.3?topic=memory-shared-objects-run-time-linking The text **In dynamic mode, input files specified with the -l flag may end in .so, as well as in .a. That is, a reference to -lfoo is satisfied by the first libfoo.so or libfoo.a found in any of the directories being searched. Dynamic mode is in effect by default unless the -bstatic option is used.** https://www.ibm.com/docs/en/aix/7.3?topic=l-ld-command Archive files are composite objects, which usually contain import files and object files, including shared objects. If an archive file contains another archive file or a member whose type is not recognized, the ld command issues a warning and ignores the unrecognized member. If an object file contained in an archive file has the F_LOADONLY bit set in the XCOFF header, the ld command ignores the member. This bit is usually used to designate old versions of shared objects that remain in the archive file to allow existing applications to load and run. New applications link with the new version of the shared object, that is, another member of the archive. > * if we do, do we want that to be bidirectional? Someone specifies *.a, do we > want to attempt to load *.so? > Considering the different scenarios, loading .a after .so failure should suffice. I got a chance to look at the right file in OpenJ9-omr ,which has a native code which does an attempt to load archive files after trying to load .so files. This code was always there and it explains why the issue did not occur in Semeru, which is derived from this repository. > When in doubt, we should just mimic what OpenJ9 is doing on AIX. But I would > like a clear documentation as a comment in os_aix.cpp explaining the logic > and referencing the relevant OpenJ9 files. > Any example comment you can refer ? I mean i just mention the file name in OpenJ9 and explain the logic ? Let me know for any further clarifications - PR Comment: https://git.openjdk.org/jdk/pull/16604#issuecomment-1909927553
Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxiliary classes [v2]
On Thu, 25 Jan 2024 06:39:56 GMT, Alexander Kriegisch wrote: >> Setting '-javaagent' is mainly an operations problem. Many build tools do >> not allow to declare a test dependency this way as the life cycles are not >> laid out for it, the internal repository location might be machine >> dependent, for example, and it's difficult to point to a specific folder >> and file reliably. In this case, I'd say it would be easier to specify a >> parameter in the sense of '-Djdk.attach.allowAttachSelf=true' as it is a >> static value. This would however only work for build tools that initiate a >> new VM for running tests which is not overly attractive for simple builds >> due to the overhead. Of course, Maven, Gradle and similar tools could set >> this parameter by default for their own JVM, that part is likely >> overcomeable but it will certainly create confusion about how to run >> libraries that are omnipresent today and make the JVM ecosystem less >> approachable. >> >> What bothers me more is the tooling perspective for non-self-attached >> agents. For example, Aaeron offers a Java agent that adds plenty of debug >> logging to relevant lines of code. This affects method size and so forth, >> with Aaeron as a high-performance tool for banking and finance which is >> written very consciously with regards to the JIT, adding it directly was >> not feasible. Normally this logging is therefore thrown into a VM in >> retrospect, once an application starts failing and is already taken off the >> load balancer. For such a post-mortem, it would be rather annoying to >> realize that a JVM cannot be attached to with full capabilities if you >> forgot to set some flag. And often you did of course not consider the VM >> instance to fail, sometimes it takes months to get a JVM into this buggy >> state. This would be fairly inconvenient to face. >> >> Therefore, I really hope that the dynamic attach from 'outside' the VM will >> survive without imposing limits and that rather the self-attachment problem >> will be targeted as such. When I mention a 'jdk.test' module in the Mockito >> context, I am also rather hoping to improve performance compared to >> convenience. The problem with '-Djdk.attach.allowAttachSelf=true' is that >> you still need to start a new VM etc. Since Java 9, running single tests >> with Mockito has for example become much slower compared to Java 8. Despite >> the startup performance improvements in the JVM. If one could avoid the >> location-bound '-javaagent:...', but get the Instrumentation instance >> directly, I think this would render a real ... > > @raphw and everyone else, I apologise for commenting on an auto-closed issue, > but I have no other way of contacting anyone, because neither do I have an > account to comment on > [JDK-8200559](https://bugs.openjdk.org/browse/JDK-8200559) nor am I a member > in any other of the JDK development or "JVM rock star" circles for good > reason: I simply have a very limited understanding of the topic at hand. > > I am, however, the current maintainer and project lead of Eclipse AspectJ, > and since JDK 16 the weaving agent requires `--add-opens > java.base/java.lang=ALL-UNNAMED` along with > `-javaagent:/path/to/aspectjweaver.jar` for the reason my predecessor Andy > Clement has explained in [AspectJ bug > 546305](https://bugs.eclipse.org/bugs/show_bug.cgi?id=546305), which is also > linked to JDK-8200559. @mlchung was also involved in the discussion there. > > Here, there has been a lot of discussion about Byte Buddy and Mockito. For > AspectJ, which is widely used in the industry, not just in Spring but also in > countless other productive contexts, there still is no solution to the > problem that we need to instrument a target class to call an auxiliary class > (generated by the agent) that does not have a Lookup object on the target > class to begin with. The target class is still being transformed, i.e. not > loaded yet, and hence we cannot look it up. > > Is this case being considered? Can any of you advise me how to solve that > problem? I am open for advice and hands-on chat, desktop sharing or > audio/video call sessions. @kriegaex I resolved this problem in Byteman by opening up the module of the target class to a module (dynamically) created by Byteman. The Instrumentation instance provided to the agent allows you to perform such an opens operation at runtime rather than on the command line. Byteman relies on an API provided by this module to create the lookups and hand them back for use in woven code. n.b. although this relies on the module exporting a public API, that API can be secured by requiring callers to pass a non-null Instrumentation instance i.e. to have agent capabilities. - PR Comment: https://git.openjdk.org/jdk/pull/3546#issuecomment-1909801331
