cleaning up the locking layers
gback at cs.utah.edu
Sun Feb 27 18:51:39 PST 2000
> These should only be used for Java object monitors. They just take a
> pointer to the Java object. The intent is that if we ever create a
> facility to log the execution of all monitorenter/exit bytecodes,
> entries and exits of synchronized methods and JNI MonitorEnter/Exit
> primitives, we'll be able to do it by tweaking this function. These
> functions are implemented as a thin layer over the VM-internal locks
> (See the next section).
> NOTE: these are functions, and must remain so, since their addresses
> are taken in some engines.
Is that a change you're proposing?
Currently, the address of the slowLock/Unlock functions is taken in
the jit3 engine; it's inlined in the code the jit emits.
Or do you mean something else?
It's also not clear to me how useful it would be to tweak lockObject
(or even slowLockObject) to log execution of monenter/exit: all inlined
uncontended acquisitions would not be logged in this case. Might still
be partially useful though.
If you define Ksem in kaffevm/ksem.h, does that mean that a threading
system cannot implement Ksem's operations as macros?
More information about the kaffe