cleaning up the locking layers

[Godmar Back]

> 
> 	lockObject(H_java_lang_Object*)
> 	unlockObject(H_java_lang_Object*)
> 
> 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.

Another question:

If you define Ksem in kaffevm/ksem.h, does that mean that a threading
system cannot implement Ksem's operations as macros?

	- Godmar