The right locks for frame rewriting / Exceptions
peter.helfer.java at gmail.com
Thu Oct 18 08:54:49 PDT 2007
I'm on the way to do some frame-hacking (patch_pc, copy some frames into
Now I need to be sure, that what I am doing is safe with regard to:
- any GC operation working on either of the two thread stacks
- neither thread is running currently on that part of the stack
= one thread must be sleeping, the other might call a VM function to do
exactly that stack-changing operation (even in its own stack..)
Q1) what kind of lock(s) is suited for this operation ?
Additionally, assume I have an interpreted method calling an interpreted
method; this one rethrows an exception - that is, the local exception
handler couldn't handle the exception. Did I get that right: (x86-specific)
- Bytecode 'athrow' calls Interpreter::throw_exception_entry() with the
exception object (oop) in RAX. This empties the expression stack and FPU
stack, and calls InterpreterRuntime::exception_handler_for_exception. This
resolves the exception into the handler for it, returning the exception in
RDX; and the handler in RAX.
The resolving process checks whether a 'catch' is around for that
(methodOop->fast_exception_handler_bci_for greater zero), adds this BCI to
the BCP, (handler_pc = h_method->code_base() + handler_bci) and returns the
dispatch table entry for that one: continuation =
Oh, Im getting off topic: if there is no handler around, it returns the
This remove_activation_entry does save the exception from the stack into
RAX, and saves RAX again in currentThread::vmResult. Now it calls
notifyJVMDI=false). After the removal, it restores the exception into RAX
(verifyOop as well), and calls just again (save temporarly RAX, RDX)
InterpreterRuntime::exception_handler_for_exception, save this result into
RBX (restore RDX, RAX) and jump there..
Q2) Now what does remove_activation exactly ? It does unlocking of objects
under certain circumstances... now could somebody literate please shed some
light on that ? I haven't figured out, how that beast works...
Q3) implicit exceptions are being generated by some fancy path leading to
THROW_MSG/THROW_OOP which finally creates a exception oop of the desired
type, and sets that for the thread:
thread->set_pending_exception(h_exception(), file, line) - but where are
they picked up again ?
PS: the next questions will be most probably about deoptimizing... be
prepared for nasty questions :-) !
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-runtime-dev