JDK-8153890 : Handle unsafe access error as an asynchronous exception
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2016-04-08
  • Updated: 2016-04-28
  • Resolved: 2016-04-28
Related Reports
Relates :  
Relates :  
Description
In certain cases, such as accessing a region of a memory mapped file which has been truncated on unix-style operating systems, a SIGBUS signal will be raised and the VM will process it in the signal handler. Currently, as part of the handling a flag is set on the thread indicating that an error has occurred:

_special_runtime_exit_condition = _async_unsafe_access_error;

Eventually the VM will check the flag and throw an InternalError. However, the flag is not always checked promptly, which means that the time between the error and the time when the InternalError is thrown can be very long.

In parallel with this, there is functionality in the VM to set pending asynchronous exceptions on threads. These asynchronous exceptions are checked/thrown more often.

Instead of having two mechanisms for handling these types of asynchronous events the unsafe access errors should be converted to use the normal asynchronous exception mechanism.

One of the reasons why this isn't already the case is that when the SIGBUS signal is raised, the thread may not be in a place where it can allocate an exception - there may not be a safepoint on the instruction performing the memory access. The solution to this is to preallocate the InternalError exception at VM start up, and have the handler code simply use that exception instead. The only downside of this is that the exception will not have a stack trace. The flip side of that is that because of the unpredictability in when the async unsafe access error is actually thrown today it is likely that the stack trace in the exception doesn't actually reflect the place where the error actually occurred anyway.

Comments
This enhancement has been superseded by JDK-8154592
28-04-2016

I think your "One reason ..." paragraph explains why this handled separately, and I think it is better handled that way - the true asynchronous exceptions (ie from Thread.stop) is quite a different beast and we want to minimize the number of things that can be entangled with it. If the responsiveness to this is the issue then perhaps just look at improving the responsiveness. But in general conversions of error conditions to exceptions only occurs when entering/returning to Java code. This is very old code with likely very obscure and complex interactions with a variety of subsystems - touching it seems quite risky.
11-04-2016