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.bate...@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 > > > > > > > >
