[External] : RE: ClassFile.build() is loading result file

Chen Liang chen.l.liang at oracle.com
Wed Jan 8 16:36:05 UTC 2025


So ClassHierarchyResolver.ofClassLoading loads system classes and inspect them with core reflection to determine their class hierarchy, based on the assumptions that the system classes are constant. However, such assumptions do not stand when agents are present, and agents do not wish system class loaded in the process of handling class files. As a result, we should inspect the class file resources instead, which is largely the same as agent-transformed classes (as agents don't usually change super classes or change classes to interfaces)

P.S. Forwarding this conversation to classfile-api-dev as this may be valuable to the public.

Regards, Chen
________________________________
From: Mark Roberts <markro at cs.washington.edu>
Sent: Wednesday, January 8, 2025 10:15 AM
To: Chen Liang <chen.l.liang at oracle.com>
Subject: RE: [External] : RE: ClassFile.build() is loading result file


Ok that worked – thank you.



Could you give me a little background on what’s going on and why the option is needed?



Thanks,

Mark



From: Chen Liang <chen.l.liang at oracle.com<mailto:chen.l.liang at oracle.com>>
Sent: Wednesday, January 8, 2025 8:05 AM
To: Mark Roberts <markro at cs.washington.edu<mailto:markro at cs.washington.edu>>
Subject: Re: [External] : RE: ClassFile.build() is loading result file



Yep; for the loader, if you are just transforming system classes, ClassLoader.getSystemClassLoader() should be sufficient.

________________________________

From: Mark Roberts <markro at cs.washington.edu<mailto:markro at cs.washington.edu>>
Sent: Wednesday, January 8, 2025 9:28 AM
To: Chen Liang <chen.l.liang at oracle.com<mailto:chen.l.liang at oracle.com>>
Subject: RE: [External] : RE: ClassFile.build() is loading result file



So would that be:



ClassFile classFile = ClassFile.of(ClassFile.ClassHierarchyResolverOption.of(ClassHierarchyResolver.ofResourceParsing(loader)));





From: Chen Liang <chen.l.liang at oracle.com<mailto:chen.l.liang at oracle.com>>
Sent: Wednesday, January 8, 2025 6:32 AM
To: Mark Roberts <markro at cs.washington.edu<mailto:markro at cs.washington.edu>>; classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org>
Subject: Re: [External] : RE: ClassFile.build() is loading result file



Use ClassHierarchyResolver.ofResourceParsing instead.



Get Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/AAb9ysg__;!!ACWV5N9M2RV99hQ!P6_3DTWkMb_9ONnHMD1wDIARAPnpbunYeeg1XeFh5H0nk8Z1fOgOb1seLBTsIqZ2Oaj2JGT2Nw9OvsRULAkfAAee3w$>

________________________________

From: Mark Roberts <markro at cs.washington.edu<mailto:markro at cs.washington.edu>>
Sent: Wednesday, January 8, 2025 8:02:16 AM
To: Chen Liang <chen.l.liang at oracle.com<mailto:chen.l.liang at oracle.com>>
Subject: [External] : RE: ClassFile.build() is loading result file



I’m sorry but I don’t understand. A documentation note doesn’t solve my problem.  What do I have to do to keep this from happening?



Mark



From: Chen Liang <chen.l.liang at oracle.com<mailto:chen.l.liang at oracle.com>>
Sent: Tuesday, January 7, 2025 7:14 PM
To: Mark Roberts <markro at cs.washington.edu<mailto:markro at cs.washington.edu>>; Chen Liang <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Cc: classfile-api-dev <classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org>>
Subject: Re: ClassFile.build() is loading result file



Thanks for this investigation. I should definitely add a note to tge class hierarchy resolver option about this side effect when this is used by instrumentation.



Chen



Get Outlook for Android<https://urldefense.com/v3/__https:/aka.ms/AAb9ysg__;!!ACWV5N9M2RV99hQ!KfAd3s_X3uwq0GUJGbBPHbRHcLwDWfvhrPGqrFqcKKKoSTvlL5zMD9oAaPcAK995QChm-syru7lSrZ4S1mQ5KRKdmA$>

________________________________

From: classfile-api-dev <classfile-api-dev-retn at openjdk.org<mailto:classfile-api-dev-retn at openjdk.org>> on behalf of Mark Roberts <markro at cs.washington.edu<mailto:markro at cs.washington.edu>>
Sent: Tuesday, January 7, 2025 8:13:03 PM
To: Chen Liang <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Cc: classfile-api-dev <classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org>>
Subject: RE: ClassFile.build() is loading result file



OK – I build my own version of java.base so I could debug this issue.  It looks like the problem is that when StackMapGenerator wants to see if something is an interface, the code ends up doing a Class.forName and loads the class being built prematurely.



  Here is the interesting call stack:



  at java.base/jdk.internal.loader.URLClassPath$FileLoader.getResource(URLClassPath.java:1073)

    at java.base/jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:315)

    at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:757)

    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)

    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)

    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)

    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:528)

    at java.base/java.lang.Class.forName0(Native Method)

    at java.base/java.lang.Class.forName(Class.java:582)

    at java.base/java.lang.Class.forName(Class.java:561)

    at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl$ClassLoadingClassHierarchyResolver$1.apply(ClassHierarchyImpl.java:223)

    at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl$ClassLoadingClassHierarchyResolver$1.apply(ClassHierarchyImpl.java:219)

    at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl$ClassLoadingClassHierarchyResolver.getClassInfo(ClassHierarchyImpl.java:243)

    at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl$CachedClassHierarchyResolver$1.apply(ClassHierarchyImpl.java:134)

    at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl$CachedClassHierarchyResolver$1.apply(ClassHierarchyImpl.java:131)

    at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1229)

    at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl$CachedClassHierarchyResolver.getClassInfo(ClassHierarchyImpl.java:142)

    at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.resolve(ClassHierarchyImpl.java:74)

    at java.base/jdk.internal.classfile.impl.ClassHierarchyImpl.isInterface(ClassHierarchyImpl.java:86)

    at java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeReferenceFrom(StackMapGenerator.java:1547)

    at java.base/jdk.internal.classfile.impl.StackMapGenerator$Type.mergeFrom(StackMapGenerator.java:1515)

    at java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.merge(StackMapGenerator.java:1376)

    at java.base/jdk.internal.classfile.impl.StackMapGenerator$Frame.checkAssignableTo(StackMapGenerator.java:1326)

    at java.base/jdk.internal.classfile.impl.StackMapGenerator.processMethod(StackMapGenerator.java:433)

    at java.base/jdk.internal.classfile.impl.StackMapGenerator.generate(StackMapGenerator.java:302)

    at java.base/jdk.internal.classfile.impl.StackMapGenerator.<init>(StackMapGenerator.java:245)

    at java.base/jdk.internal.classfile.impl.StackMapGenerator.of(StackMapGenerator.java:156)

    at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.generateStackMaps(DirectCodeBuilder.java:317)

    at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.tryGenerateStackMaps(DirectCodeBuilder.java:325)

    at java.base/jdk.internal.classfile.impl.DirectCodeBuilder$4.writeBody(DirectCodeBuilder.java:360)

    at java.base/jdk.internal.classfile.impl.UnboundAttribute$AdHocAttribute.writeTo(UnboundAttribute.java:835)

    at java.base/jdk.internal.classfile.impl.Util.writeAttribute(Util.java:230)

    at java.base/jdk.internal.classfile.impl.AttributeHolder.writeTo(AttributeHolder.java:71)

    at java.base/jdk.internal.classfile.impl.DirectMethodBuilder.writeTo(DirectMethodBuilder.java:146)

    at java.base/jdk.internal.classfile.impl.Util.writeList(Util.java:247)

    at java.base/jdk.internal.classfile.impl.DirectClassBuilder.build(DirectClassBuilder.java:198)

    at java.base/jdk.internal.classfile.impl.ClassFileImpl.build(ClassFileImpl.java:146)

    at java.base/java.lang.classfile.ClassFile.build(ClassFile.java:333)

    at daikon.chicory.Instrument.transform(Instrument.java:295)

    at java.instrument/java.lang.instrument.ClassFileTransformer.transform(ClassFileTransformer.java:259)

    at java.instrument/sun.instrument.TransformerManager.transform(TransformerManager.java:188)

    at java.instrument/sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:611)

    at java.base/java.lang.ClassLoader.defineClass1(Native Method)

    at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1026)

    at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)

    at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)

    at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)

    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)

    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)

    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)

    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:528)

    at java.base/java.lang.ClassLoader.defineClass1(Native Method)

    at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1026)

    at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)

    at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)

    at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)

    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)

    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)

    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)

    at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:528)

    at javautil.ArrayList17Test.main(ArrayList17Test.java:7)



Thank you,

Mark



From: Mark Roberts <markro at cs.washington.edu<mailto:markro at cs.washington.edu>>
Sent: Monday, January 6, 2025 12:51 PM
To: 'Chen Liang' <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Cc: 'classfile-api-dev' <classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org>>
Subject: RE: ClassFile.build() is loading result file



I modified the jvmti minst tool to capture java execution method enter and exit.  I have attached what I hope is the relevant part of the log file.  This section of the log file starts with:

daikon.chicory.Instrument.modifyClass exit

and ends with:

java.lang.LinkageError: loader 'app' attempted duplicate abstract class definition for javautil.AbstractList17.



Along the way you can see the load:

 [6.689s][info][class,load] javautil.AbstractList17 source: file:/scratch/markro/tests/scratch/markro/clones/mydaikon.24/tests/daikon-tests/ArrayList17/

Happening twice.  The second time is expected when the code exits the transform method.  This first seems like an error that occurs at some point while the DirectCodeBuilder is running.



Hope this helps to debug my problem.



Thank you,

Mark





From: Chen Liang <liangchenblue at gmail.com<mailto:liangchenblue at gmail.com>>
Sent: Sunday, January 5, 2025 2:06 PM
To: Mark Roberts <markro at cs.washington.edu<mailto:markro at cs.washington.edu>>
Cc: classfile-api-dev <classfile-api-dev at openjdk.org<mailto:classfile-api-dev at openjdk.org>>
Subject: Re: ClassFile.build() is loading result file



Hi Mark,
why do you need to supply the ClassLoader to the modifyClass method? Class file transformation should have no dependency on the CHA process, and the only need is encapsulated within the ClassFile context object.

Can you post your modifyClass?

Chen



On Sun, Jan 5, 2025, 2:57 PM Mark Roberts <markro at cs.washington.edu<mailto:markro at cs.washington.edu>> wrote:

I am using ClassFileTransformer.transform() to instrument class files as they are loaded.   Within my transform method I call



byte[] newBytes =  classFile.build(classModel.thisClass().asSymbol(),

                          classBuilder -> modifyClass(classBuilder, classModel, loader));



where modifyClass does all the instrumentation.



The problem is some where inside of classFile.build() the class is actually being loaded!  Thus, when I return newBytes from the transform method I get an error ‘attempted duplicate abstract class definition’. I have verified that the class has not be loaded prior to the return from modifyClass().



What is going on?



Thank you,

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250108/2b91ed57/attachment-0001.htm>


More information about the classfile-api-dev mailing list