Constant Descriptors usage and Latest versions
-
liangchenblue at gmail.com
Tue Jun 27 14:38:55 UTC 2023
I have submitted an issue https://bugs.openjdk.org/browse/JDK-8310848
and a patch https://github.com/openjdk/jdk/pull/14640 for 2, fixing up
existing JDK usages.
Adam, can you review it?
Chen Liang
On Wed, Jun 21, 2023 at 1:04 PM - <liangchenblue at gmail.com> wrote:
>
> For 1 and 3, there's currently Classfile context object migration, so
> I think I can create an issue and send a pull request to Adam's fork
> updating the Classfile interface.
>
> For 2, this problem is actually more related to the Constant API, for
> Constant Descriptors themselves are prime candidates to be Constable,
> as they are already immutable. I just happened to find that we
> construct reusable MethodTypeDesc each time a method is called in the
> SystemModulesPlugin migration, which makes my attempts to speed up
> MethodTypeDesc::descriptorString less meaningful. I can create an
> issue and a patch to convert existing JDK usages to use from static
> final fields whenever possible; and we can additionally update the API
> specification asking users to store in static final fields like for
> the Vector API.
>
> On Wed, Jun 21, 2023 at 9:53 AM Brian Goetz <brian.goetz at oracle.com> wrote:
> >
> >
> >
> > > 1. LATEST_MAJOR_VERSION and LATEST_MINOR_VERSION should become static
> > > methods: otherwise, javac will inline the constant values, making a
> > > program compiled with an older JDK unable to fetch the latest Major
> > > class file version.
> >
> > Good catch.
> >
> > > 2. Many usages (in user code) of Constant Descriptors from
> > > java.lang.constant package are somewhat inefficient: for instance,
> > > ClassDesc and MethodTypeDesc should both be stored in static final
> > > fields than constructed on each call; MethodTypeDesc should be
> > > constructed with a parameter array instead of with a descriptor
> > > string, as descriptor string parsing has been proven slow in recent
> > > benchmarks.
> >
> > The XxxDesc-accepting methods were built on top of XxxEntry-accepting
> > methods, so you should be able to do everything you need (just with
> > fewer seat belts) by constructing constant pool entries using UTF8
> > descriptors.
> >
> > Are there other changes you want to suggest here, or are you making a
> > suggestion for the docs? Having a section on constant pool entries /
> > descriptors in the package javadoc would make sense.
> >
> > > 3. We should probably have a set of char constants for annotation tags
> > > in Classfile as well.
> > >
> >
> > Seems reasonable.
> >
> > No objections to any of this. Would you like to propose something concrete?
More information about the classfile-api-dev
mailing list