MH inlining fails for a package-private and protected calls

Paul Sandoz paul.sandoz at oracle.com
Mon Oct 27 17:23:30 UTC 2014


On Oct 25, 2014, at 12:00 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> Paul,
> 
> Accessibility is not a problem. The reason is profile pollution, since
> DMH bytecode is shared:
> * MHInlineTest::testPublicMH
> @ 13   java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes)   force inline by annotation
> 
> * MHInlineTest::testProtectedMH (24 bytes)   inline (hot)
> @ 13   java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes)   force inline by annotation
> 
> * MHInlineTest::testPackageMH (24 bytes)   inline (hot)
> 
> @ 13   java.lang.invoke.LambdaForm$DMH/285377351::invokeVirtual_LL_V (15 bytes)   force inline by annotation
> 
> If you reorder the tests or mix then, inlining behavior will change.
> 
> Don't know why LambdaForm is different for testPackageFinalMH case.
> 

I presume because it is a final method and linkToSpecial can be used instead?

Perhaps my example is a little misleading regarding profile pollution. FWIW i could not get any indication from the inlining or method data output that profiling was an issue.

See below for a simpler case that just calls a package-private method on a static final instance of A:

               !            @ 10   MHInlineSimpleTest::testPackageMH (24 bytes)   inline (hot)
                              @ 7   java.lang.invoke.LambdaForm$MH/708049632::invokeExact_MT (17 bytes)   force inline by annotation
                                @ 2   java.lang.invoke.Invokers::checkExactType (30 bytes)   force inline by annotation
                                  @ 11   java.lang.invoke.MethodHandle::type (5 bytes)   accessor
                                @ 13   java.lang.invoke.LambdaForm$DMH/385242642::invokeVirtual_LL_V (15 bytes)   force inline by annotation
                                  @ 1   java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes)   force inline by annotation
                                  @ 11   MHInlineSimpleTest$A::package_x (6 bytes)   virtual call
                            @ 4   MHInlineSimpleTest$A::package_x (6 bytes)   inline (hot)
                            @ 29   MHInlineSimpleTest::testPackage (8 bytes)   inline (hot)
                              @ 4   MHInlineSimpleTest$A::package_x (6 bytes)   inline (hot)

This appears to indicate there is something more fundamental going on. Is there some information lost when unpacking the underlying method characterized by member name passed to MH.linkToVirtual?

AFAICT an access control check fails for the lambda form to access the protected method when attempting to inline the method handle.


> I'll look into this on Monday.
> 

Thanks,
Paul.

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;

public class MHInlineSimpleTest {

    public static class A {
        volatile String s;

        void package_x(String s) {
            this.s = s;
        }
    }

    static final MethodHandle A_PACKAGE_X;

    static {
        try {
            A_PACKAGE_X = MethodHandles.lookup().in(A.class).findVirtual(
                    A.class, "package_x", MethodType.methodType(void.class, String.class));
        }
        catch (Exception e) {
            throw new Error(e);
        }
    }

    static final A a = new A();

    public static void main(String[] args) {
        for (int i = 0; i < 1000_0000; i++) {
            testPackageMH("X");
        }
        for (int i = 0; i < 1000_0000; i++) {
            testPackage("X");
        }
        System.out.println("END");
    }

    private static void testPackageMH(String x) {
        try {
            A_PACKAGE_X.invokeExact(a, x);
        }
        catch (Throwable throwable) {
            throw new Error(throwable);
        }
    }

    private static void testPackage(String x) {
        a.package_x(x);
    }
}

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20141027/b20b495c/signature-0001.asc>


More information about the hotspot-compiler-dev mailing list