Second call for reviews. I need two official Reviewers for this change. — John
P.S. Thanks for your comments Morris; I enhanced the comment: + // The JVM does this hack also. ++ // (See ClassVerifier::verify_invoke_instructions ++ // and LinkResolver::check_method_accessability.) ++ // Because the JVM does not allow separate methods on array types, + // there is no separate method for int[].clone. + // All arrays simply inherit Object.clone. + // But for access checking logic, we make Object.clone + // (normally protected) appear to be public. + // Later on, when the DirectMethodHandle is created, + // its leading argument will be restricted to the + // requested array type. ++ // N.B. The return type is not adjusted, because ++ // that is *not* the bytecode behavior. Oddly, the JVMS does not mention this hack explicitly. Maybe it's buried in the Prolog code. On Sep 21, 2013, at 2:34 AM, Morris Meyer <morris.me...@oracle.com> wrote: > This looks good. Might want to point out where in HotSpot this change > originates from in your comment. > > --mm > > >> On Sep 18, 2013, at 10:32 PM, John Rose <ros...@me.com> wrote: >> >> http://cr.openjdk.java.net/~jrose/8001105/webrev.00/ >> >> Summary: Replicate JVM logic for access control that makes Object.clone >> appear public when applied to an array type. >> >> See: http://mail.openjdk.java.net/pipermail/mlvm-dev/2012-October/005035.html >> >> — John >> >> >> _______________________________________________ >> mlvm-dev mailing list >> mlvm-dev@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
