j.l.instrument is for tool agent so better to discuss on
serviceability-dev rather than here.
Thanks for letting me know; I will respond with this mail here to the
thread there then.
For future reference, the original thread was:
https://mail.openjdk.org/archives/list/[email protected]/thread/HDXAJP5GKR3RXGBZ7SO4IC67YFMYBTPB/
That said, the setup in that closed JBS issue is very strange. The
purpose of appendToBootstrapClassLoaderSearch is to allow
instrumentation of classes in the modules mapped to the boot loader
where the instrumentation adds references to supporting classes
provided by the agent. These classes cannot be unloaded and it seems a
bit reckless to be trying to delete JAR files that may be in use. It
may be that the usages need to be looked at to find out why the agent
in this examples cited is creating hundreds of JAR files in the temp
location.
The reason is that `appendToBootstrapClassLoaderSearch` requires a
JarFile, i.e. a file on disk. However, callers of it often only want to
add a few specific classes to the bootstrap class loader and therefore
resort to creating a temp JAR containing only those classes (example [1]).
Alternatives are error-prone:
* Adding the enclosing JAR file (1) is error prone when having to use
`Class#getProtectionDomain` or similar to determine the JAR file
path first and (2) includes a lot of classes which should not be
added to the bootstrap class loader (an even bigger problem when the
`appendToBootstrapClassLoaderSearch` call is in a library, and users
might have repackaged/shaded that library, including even more
unrelated classes).
* Trying to create the JarFile only once and reusing it is error-prone
for concurrent JVM processes, where one might see an incomplete
JarFile then.
So the effect is that an agent has to create a new temp JarFile every
time when using `appendToBootstrapClassLoaderSearch`. On Linux that is
not a problem because the temp file can be deleted again (the file
system entry disappears but the JVM still has an open handle and access
its contents). On Windows this is not possible so there is no proper way
to clean up the temp files again (without risking concurrency bugs or
requiring complex logic), so the temp files keep accumulating in the
temp directory, as described in the JDK bug report.
For projects like Mockito I mentioned as example, that happens every
time you run unit tests in a project using Mockito, so the amount of
temp files in %TEMP% becomes noticeable. For my use case it is probably
not as often, but it would still be desirable to avoid leaving behind
temp files.
So it is not necessarily that agents want to delete the temp JarFile
while it is still the use, rather the opposite, they want to delete it
when it is not in use anymore. But there is currently no way to do that.
That is why I was asking / proposing whether DELETE_ON_CLOSE would
support that.
Kind regards
[1]
https://github.com/mockito/mockito/blob/a231205b240e7884a63bf0f63440012867a4da21/mockito-core/src/main/java/org/mockito/internal/creation/bytebuddy/InlineDelegateByteBuddyMockMaker.java#L142-L174
