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: 2012-10-09
  • 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 :  
Relates :  
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
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