How can methods throwing exceptions be inlined?

I'm just curious as to how it is possible for the Java JVM to sometimes inline methods that have the potential to throw exceptions. I assume that it's possible to inline at least some such methods (such as those that have array accesses and hence the potential to throw ArrayIndexOutOfBoundsExceptions). The problem I see is that if the ex开发者_Python百科ception actually occurs, how do you show the proper stack trace if you've inlined the method? Since different methods can be inlined on different machines, how does inlining not break the stack trace mechanism?

What is the problem you envisage? Since it is the JVM itself that does the inlining, there is nothing that prevents it from remembering what it inlined where and correct for this when it constructs a stack trace to install in a Throwable object.

When an exception is thrownconstructed, the JVM will walk the CPU stack and figure out whether each machine stack frame corresponds to interpreted bytecode, JITted code, native code from libraries and so forth. For this it refers to tables that tell which addresses in the machine code corresponds to which instructions from the bytecode (and further back to source lines, if that information is pressent in the class file). This table can perfectly well specify that a certain place in JITted code can correspond to more than one Java-level stack frame.

However, a JVM is not required to do this. It may also choose simply to construct stack traces with mysterious breaks in them. See the javadoc for Throwable.getStackTrace(). (There is even no requirement that a JVM is able to produce stack traces at all).

You might want to check out this document which explains how exception handling works in the JVM:

Each method that catches exceptions is associated with an exception table that is delivered in the class file along with the bytecode sequence of the method. The exception table has one entry for each exception that is caught by each try block. Each entry has four pieces of information: the start and end points, the pc offset within the bytecode sequence to jump to, and a constant pool index of the exception class that is being caught.