The right locks for frame rewriting / Exceptions

[Peter Helfer]

Hi all

I'm on the way to do some frame-hacking (patch_pc, copy some frames into
another thread..)

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 =
Interpreter::dispatch_table(vtos)[*handler_pc];
Oh, Im getting off topic: if there is no handler around, it returns the
Interpreter::remove_activation_entry().

This remove_activation_entry does save the exception from the stack into
RAX, and saves RAX again in currentThread::vmResult. Now it calls
masm->remove_activation(TosState=vtos, returnaddr=rdx,
throwMonitorException=false, installMonitorException=true,
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 ?



Regards, Peter



PS: the next questions will be most probably about deoptimizing... be
prepared for nasty questions :-) !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20071018/f1c45f14/attachment.html