Lois identified and fixed a bug found when running the JCK VM tests. I merged 
the changes below into the current webrev.

Paul.

--- old/src/hotspot/share/interpreter/linkResolver.cpp  2017-10-31 
11:56:30.541287505 -0400
+++ new/src/hotspot/share/interpreter/linkResolver.cpp  2017-10-31 
11:56:29.215676272 -0400
@@ -301,14 +301,14 @@
   if (vca_result != Reflection::ACCESS_OK) {
     ResourceMark rm(THREAD);
     char* msg = Reflection::verify_class_access_msg(ref_klass,
-                                                    
InstanceKlass::cast(sel_klass),
+                                                    
InstanceKlass::cast(base_klass),
                                                     vca_result);
     if (msg == NULL) {
       Exceptions::fthrow(
         THREAD_AND_LOCATION,
         vmSymbols::java_lang_IllegalAccessError(),
         "failed to access class %s from class %s",
-        sel_klass->external_name(),
+        base_klass->external_name(),
         ref_klass->external_name());
     } else {
       // Use module specific message returned by verify_class_access_msg().


 
> On 26 Oct 2017, at 10:03, Paul Sandoz <paul.san...@oracle.com> wrote:
> 
> Hi,
> 
> Please review the following patch for minimal dynamic constant support:
> 
>  
> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/
>  
> <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8186046-minimal-condy-support-hs/webrev/>
> 
>  https://bugs.openjdk.java.net/browse/JDK-8186046 
> <https://bugs.openjdk.java.net/browse/JDK-8186046>
>  https://bugs.openjdk.java.net/browse/JDK-8186209 
> <https://bugs.openjdk.java.net/browse/JDK-8186209>
> 
> This patch is based on the JDK 10 unified HotSpot repository. Testing so far 
> looks good.
> 
> By minimal i mean just the support in the runtime for a dynamic constant pool 
> entry to be referenced by a LDC instruction or a bootstrap method argument. 
> Much of the work leverages the foundations built by invoke dynamic but is 
> arguably simpler since resolution is less complex.
> 
> A small set of bootstrap methods will be proposed as a follow on issue for 10 
> (these are currently being refined in the amber repository).
> 
> Bootstrap method invocation has not changed (and the rules are the same for 
> dynamic constants and indy). It is planned to enhance this in a further major 
> release to support lazy resolution of bootstrap method arguments.
> 
> The CSR for the VM specification is here:
> 
>  https://bugs.openjdk.java.net/browse/JDK-8189199 
> <https://bugs.openjdk.java.net/browse/JDK-8189199>
> 
> the j.l.invoke package documentation was also updated but please consider the 
> VM specification as the definitive "source of truth" (we may clean up this 
> area further later on so it becomes more informative, and that may also apply 
> to duplicative text on MethodHandles/VarHandles).
> 
> Any AoT-related work will be deferred to a future release.
> 
> —
> 
> This patch only supports x64 platforms. There is a small set of changes 
> specific to x64 (specifically to support null and primitives constants, as 
> prior to this patch null was used as a sentinel for resolution and certain 
> primitives types would never have been encountered, such as say byte).
> 
> We will need to follow up with the SPARC platform and it is hoped/anticipated 
> that OpenJDK members responsible for other platforms (namely ARM and PPC) 
> will separately provide patches.
> 
> —
> 
> Many of tests rely on an experimental byte code API that supports the 
> generation of byte code with dynamic constants.
> 
> One test uses class file bytes produced from a modified version of asmtools.  
> The modifications have now been pushed but a new version of asmtools need to 
> be rolled into jtreg before the test can operate directly on asmtools 
> information rather than embedding class file bytes directly in the test.
> 
> —
> 
> Paul.

Reply via email to