RFR (S) 8001105: findVirtual of Object[].clone produces internal error

[John Rose]

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.meyer at 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 <rose00 at 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 at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev