ClassLoader API to look up class files

[Rafael Winterhalter]

In Byte Buddy, class files are typically looked up from a Java agent or a
build tool plugin. The underlying abstraction is a ClassFileLocator. In a
build tool, the locator is typically based on jar files or folders. Here,
the locator can determine that a jar or folder is multi-release by a
possible manifest. This is so rarely the case that it has not played a big
role in performance tests. And the file lookups are cheapish.

For an agent, however, the question is harder. An agent can only query
classes or resources from a class loader. Classes are often off limit as it
should avoid loading classes what often results in circularities. That's
why class files are loaded as resources. To make things worse, a class
loader can represent about anything, so the costs are unknown.

Therefore, even if the class loader preindexed Multi-Release versions of
classes to load, this would not automatically solve the issue for reading
class files as resources.

If the internal mechanism for multi-release jars was improved, I would
therefore hope that this fast-path access is exposed somehow via an API as
the one I suggested.

With the manual iteration over possible names on the other side, I can see
that this currently slows down the agent around 10% on a regular app,
compared to ignoring multi release jars from agents.

Thanks, Rafael

Am So., 22. Sept. 2024 um 09:46 Uhr schrieb Alan Bateman <
alan.bateman at oracle.com>:

> On 21/09/2024 22:14, Rafael Winterhalter wrote:
> > Hello,
> > It is a quite common need for Java agents to resolve class files for
> > Java classes by their name. Normally, this is done by requesting a
> > resource from the class loader.
>
> I agree that the scalability issue with MR JARs deserves attention. JEP
> 238 pre-dates the 6 month cadence where we now add two additional
> versions to search each year. I don't think this issue is really
> anything to do with Java agents or the ClassLoader API, instead this is
> about the JarFile implementation. Some experiments needed but it may be
> more efficient to find and cache the names of the entries that are
> versioned, and avoid looping through the versions altogether.
>
> -Alan
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240922/a3f503ae/attachment.htm>