Hi Mandy,
Good work.
I'm trying to find out which language use-case is covered by the
InnerClassLambdaMetafactory needing to inject method handle into the
generated proxy class to be invoked instead of proxy class directly
invoking the method:
useImplMethodHandle =
!implClass.getPackageName().equals(implInfo.getDeclaringClass().getPackageName())
&&
!Modifier.isPublic(implInfo.getModifiers());
If I check what implClass and implInfo get resolved to in
AbstractValidatingLambdaMetafactory, there are several cases:
this.implInfo = caller.revealDirect(implMethod);
switch (implInfo.getReferenceKind()) {
case REF_invokeVirtual:
case REF_invokeInterface:
this.implClass = implMethodType.parameterType(0);
// reference kind reported by implInfo may not match
implMethodType's first param
// Example: implMethodType is (Cloneable)String,
implInfo is for Object.toString
this.implKind = implClass.isInterface() ?
REF_invokeInterface : REF_invokeVirtual;
this.implIsInstanceMethod = true;
break;
case REF_invokeSpecial:
// JDK-8172817: should use referenced class here, but
we don't know what it was
this.implClass = implInfo.getDeclaringClass();
this.implIsInstanceMethod = true;
// Classes compiled prior to dynamic nestmate support
invokes a private instance
// method with REF_invokeSpecial.
//
// invokespecial should only be used to invoke private
nestmate constructors.
// The lambda proxy class will be defined as a nestmate
of targetClass.
// If the method to be invoked is an instance method of
targetClass, then
// convert to use invokevirtual or invokeinterface.
if (targetClass == implClass &&
!implInfo.getName().equals("<init>")) {
this.implKind = implClass.isInterface() ?
REF_invokeInterface : REF_invokeVirtual;
} else {
this.implKind = REF_invokeSpecial;
}
break;
case REF_invokeStatic:
case REF_newInvokeSpecial:
// JDK-8172817: should use referenced class here for
invokestatic, but we don't know what it was
this.implClass = implInfo.getDeclaringClass();
this.implKind = implInfo.getReferenceKind();
this.implIsInstanceMethod = false;
break;
default:
throw new
LambdaConversionException(String.format("Unsupported MethodHandle kind:
%s", implInfo));
}
For majority of cases (REF_invokeSpecial, REF_invokeStatic,
REF_newInvokeSpecial) the this.implClass = implInfo.getDeclaringClass();
Only REF_invokeVirtual and REF_invokeInterface are possible kandidates,
right?
So when does the implMethod type of parameter 0 differ from the
declaring class of the MethodHandleInfo cracked from that same
implMethod and in addition those two types leave in different packages?
Regards, Peter
On 3/27/20 12:57 AM, Mandy Chung wrote:
Please review the implementation of JEP 371: Hidden Classes. The main
changes are in core-libs and hotspot runtime area. Small changes are
made in javac, VM compiler (intrinsification of Class::isHiddenClass),
JFR, JDI, and jcmd. CSR [1]has been reviewed and is in the finalized
state (see specdiff and javadoc below for reference).
Webrev:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03
Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point
of view, a hidden class is a normal class except the following:
- A hidden class has no initiating class loader and is not registered
in any dictionary.
- A hidden class has a name containing an illegal character
`Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature`
returns "Lp/Foo.0x1234;".
- A hidden class is not modifiable, i.e. cannot be redefined or
retransformed. JVM TI IsModifableClass returns false on a hidden.
- Final fields in a hidden class is "final". The value of final
fields cannot be overriden via reflection. setAccessible(true) can
still be called on reflected objects representing final fields in a
hidden class and its access check will be suppressed but only have
read-access (i.e. can do Field::getXXX but not setXXX).
Brief summary of this patch:
1. A new Lookup::defineHiddenClass method is the API to create a
hidden class.
2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG
option that
can be specified when creating a hidden class.
3. A new Class::isHiddenClass method tests if a class is a hidden class.
4. Field::setXXX method will throw IAE on a final field of a hidden class
regardless of the value of the accessible flag.
5. JVM_LookupDefineClass is the new JVM entry point for
Lookup::defineClass
and defineHiddenClass to create a class from the given bytes.
6. ClassLoaderData implementation is not changed. There is one
primary CLD
that holds the classes strongly referenced by its defining loader.
There
can be zero or more additional CLDs - one per weak class.
7. Nest host determination is updated per revised JVMS 5.4.4. Access
control
check no longer throws LinkageError but instead it will throw IAE with
a clear message if a class fails to resolve/validate the nest host
declared
in NestHost/NestMembers attribute.
8. JFR, jcmd, JDI are updated to support hidden classes.
9. update javac LambdaToMethod as lambda proxy starts using nestmates
and generate a bridge method to desuger a method reference to a
protected
method in its supertype in a different package
This patch also updates StringConcatFactory, LambdaMetaFactory, and
LambdaForms
to use hidden classes. The webrev includes changes in nashorn to
hidden class
and I will update the webrev if JEP 372 removes it any time soon.
We uncovered a bug in Lookup::defineClass spec throws LinkageError and
intends
to have the newly created class linked. However, the implementation
in 14
does not link the class. A separate CSR [2] proposes to update the
implementation to match the spec. This patch fixes the implementation.
The spec update on JVM TI, JDI and Instrumentation will be done as
a separate RFE [3]. This patch includes new tests for JVM TI and
java.instrument that validates how the existing APIs work for hidden
classes.
javadoc/specdiff
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/
JVMS 5.4.4 change:
http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf
CSR:
https://bugs.openjdk.java.net/browse/JDK-8238359
Thanks
Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-8238359
[2] https://bugs.openjdk.java.net/browse/JDK-8240338
[3] https://bugs.openjdk.java.net/browse/JDK-8230502