JDK-6308271 : JVMS: clarify description of resolution to indicate that VirtualMachineErrors should not be cached
  • Type: Bug
  • Component: specification
  • Sub-Component: vm
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-08-09
  • Updated: 2025-02-02
  • Resolved: 2007-06-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 1.6Fixed
Related Reports
Relates :  
JDK-6261890 - nsk/stress/stack/stack001 test fail with StackOverflowError exception
Relates :  
JDK-6471091 - java.lang.NoSuchMethodError: java.lang.ThreadDeath: method (Ljava/lang/String;)V not found
Description
Section 5.4.3 of the VM spec describes how symbolic references in the constant pool are resolved. If the first attempt to resolve a symbolic reference fails then subsequent attempts are required to fail with the same error as the initial attempt. One minor point with the current wording is that the description doesn't make it clear if virtual machine errors (StackOverflowError, OutOfMemoryError, InternalError) should be cached like genuine errors. According to Gilad, these are special cases and not what was intended by the spec. It would be good to have this clarified in a future revision of the specification.
Comments
Just for future readers, it seems we still do not quite capture this intent in the JVMS: 5.4.3: If an error occurs during resolution of the symbolic reference, then it is either (i) an instance of IncompatibleClassChangeError (or a subclass); (ii) an instance of Error (or a subclass) that arose from resolution or invocation of a bootstrap method; or (iii) an instance of LinkageError (or a subclass) that arose because class loading failed or a loader constraint was violated. The error must be thrown at a point in the program that (directly or indirectly) uses the symbolic reference. This now seems to preclude the possibility of non-LinkageError errors from occurring during VM resolution. Even worse the addition of BSM's to the resolution process means that a BSM can throw absolutely any kind of error and it is supposed to be treated as a resolution error that is saved and rethrown - which is problematic to say the least - see JDK-8349141.
02-02-2025
EVALUATION During initialization, StackOverflowError and other VM errors are not treated specially. Thus, like other exceptions and errors, they stop a class's initialization permanently. The reason is that arbitrary code in static initializers can cause StackOverflowErrors and OutOfMemoryErrors (among other exceptions and errors). It's not worth giving such code the benefit of the doubt ("Maybe the static{...} block won't overflow the stack next time") by permitting class initialization to be retried. Resolution is different because everything that needs to be loaded is already loaded, and no user code is involved. If resolution fails with a VM error, the VM state is undoubtedly imperfect (e.g. no memory left) but it's worth giving the VM code the benefit of the doubt should the resolution comes round again. A member isn't inherently irresolvable because the VM was once out of memory. So, VM errors shouldn't be cached during resolution, only LinkageErrors. JVMS 5.4.3 should say: "If an attempt by the Java virtual machine to resolve a symbolic reference fails because a LinkageError (or a subclass) is thrown, then subsequent attempts to resolve the reference always fail with the same error that was thrown as a result of the initial resolution attempt."
20-11-2006