Re: [Sablevm-developer] acquiring monitor

[Archie C. <ar...@de...>]

David Paul BELANGER wrote:
> In the reflection methods already implemented such as
> nativeGetMethod() (file: java_lang_Class.c), a global monitor is
> acquired.
> 
> boolean monitor_acquired = JNI_FALSE;
> 
> if (_svmf_enter_object_monitor
>     (env,
>     *(vm->class_loading.boot_loader.classes.virtualmachine->
>    class_instance)) != JNI_OK)
> 					      
> The create/link class methods acquire the same monitor and gc allocated
> function seem to have a global mutex.  I don't quite see the reason of
> acquiring that monitor.  Is it needed for correctness (protecting
> concurrent access to a function I overlooked or create/link/initialize
> needs to be done as a block) or is it to avoid
> acquiring/releasing the monitor several times (link_class,
> create_class) i.e. for efficiency as acquiring a lock already own is
> faster?

As I understand things, the VirtualMachine monitor is used to
protect the internal java type data structures.

In the case of Class.getMethod() (and therefore Class.nativeGetMethod())
the spec says that accessing the Method object associated with a
class is an "active use" and so the class must be linked if it hasn't
already been linked. And linking the class's type of course requires
acquiring the monitor.

-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com