RFR (S) 8023697: failed class resolution reports different class name in detail message for the ,first and subsequent times
coleen.phillimore at oracle.com
Wed Apr 30 21:41:25 UTC 2014
Karen, Thank you for looking at the code.
On 4/28/14, 6:11 PM, Karen Kinnear wrote:
> A couple of comments/questions:
> 1. Can you possibly measure footprint in a large application to see if the saved error messages use significant footprint?
I ran medrec and dacapo. Only failed constant pool resolutions are
cached in this resolution error table. For these applications there was
only one entry in this hashtable, so the footprint increase for both the
pointer and the refcounted Symbol (which is the class name) is
mimimal. The spec requires that the JVM throw the same exception for
subsequent resolutions from the constant pool. For the field and method
cases, we repeat the resolution steps and get the same answer. Only
for classes, method handles and method types, do we save the resolution
error. The resolution error is for errors during class loading from
constant pool symbolic reference in the spec 5.3 paragraph 1 and does
not include errors for linking and initializing the class. The error
conditions for this are saved with a different mechanism
> 2. I'm concerned about setting expectations that the detailed message will be repeated precisely for constant pool resolution
> - but for now that is only for Class, MethodHandle and MethodType resolution
Since the JVM repeats the attempted resolution for these other types of
constant pool resolution, the message will already be the same.
> 3. A comment in the bug report says that for linkage errors in SD the detail message is the name of the class, in all cases but this one, the
> message is the same
> - I'm confused - did you test this with for instance a LoaderConstraint test - doesn't that have a different detail message?
I fixed the comment in the bug. For the case in the test, where the
error came from the super class not found, the message refers to the
super class. For all the other testing I did, since we save the name of
the class in the error message. The loader constraint test does not
save the error in the resolution error table.
In investigating this, I found there were two parameters unused in
handle_resolution_exception() so cleaned them up too.
open webrev at http://cr.openjdk.java.net/~coleenp/8023697_2/
> I appreciate consolidating the duplicate code.
> On Apr 28, 2014, at 5:07 PM, Coleen Phillimore wrote:
>> Summary: Cache detail message when we cache exception for constant pool resolution.
>> In the resolution error table. Provide a default message if one is not in the original exception. Also, consolidate duplicate code for MethodHandleInError and MethodTypeInError with UnresolvedClassInError.
>> open webrev athttp://cr.openjdk.java.net/~coleenp/8023697/
>> bug linkhttps://bugs.openjdk.java.net/browse/JDK-8023697
>> Ran jck8, ute vm.quick.testlist, jtreg tests in hotspot/test, java/lang/invoke jdk jtreg tests.
More information about the hotspot-runtime-dev