sablevm-developer

[Sablevm-developer] acquiring monitor

[David P. B. <db...@CS...>]

Hi,

In the reflection methods already implemented such as
nativeGetMethod() (file: java_lang_Class.c), a global monitor is
acquired.

boolean monitor_acquired =3D JNI_FALSE;

if (_svmf_enter_object_monitor
    (env,
    *(vm->class_loading.boot_loader.classes.virtualmachine->
   class_instance)) !=3D JNI_OK)
					     =20
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?

David


---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

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

Re: [Sablevm-developer] acquiring monitor

[David P. B. <db...@CS...>]

On Sun, Feb 09, 2003 at 02:43:06PM -0800, Archie Cobbs wrote:
> David Paul BELANGER wrote:
> > In the reflection methods already implemented such as
> > nativeGetMethod() (file: java_lang_Class.c), a global monitor is
> > acquired.
> >=20
> > boolean monitor_acquired =3D JNI_FALSE;
> >=20
> > if (_svmf_enter_object_monitor
> >     (env,
> >     *(vm->class_loading.boot_loader.classes.virtualmachine->
> >    class_instance)) !=3D JNI_OK)
> > 					     =20
> > The create/link class methods acquire the same monitor and gc allocat=
ed
> > function seem to have a global mutex.  I don't quite see the reason o=
f
> > acquiring that monitor.  Is it needed for correctness (protecting
> > concurrent access to a function I overlooked or create/link/initializ=
e
> > 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?
>=20
> As I understand things, the VirtualMachine monitor is used to
> protect the internal java type data structures.
>=20
> 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.
>=20

Yes, I do understand that part but the link functions do acquire it.
I am wondering why we have this structure:

acquire monitor
.
.
.
link_class()
  (inside link_class)
  acquire monitor
  .
  .
  .
  release monitor
.
initialize_class
  acquire monitor
  .
  .
  release monitor
.
.
release monitor


What functions are we protecting with the external acquire monitor?

Thanks,
David


> -Archie
>=20
> _______________________________________________________________________=
___
> Archie Cobbs     *     Packet Design     *     http://www.packetdesign.=
com

--=20

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

Re: [Sablevm-developer] acquiring monitor

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

David Paul BELANGER wrote:
> > 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.
> 
> Yes, I do understand that part but the link functions do acquire it.
> I am wondering why we have this structure:
> 
> acquire monitor
> .
> .
> .
> link_class()
>   (inside link_class)
>   acquire monitor
>   .
>   .
>   .
>   release monitor
> .
> initialize_class
>   acquire monitor
>   .
>   .
>   release monitor
> .
> .
> release monitor
> 
> What functions are we protecting with the external acquire monitor?

Maybe it's for the creation of the new Method reflection instance?
The JVM must ensure that it only gets created once.

-Archie

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

Re: [Sablevm-developer] acquiring monitor

[Etienne M. G. <eti...@uq...>]

Hi David,

Archie is right; synchronization is needed to avoid creating more than
one Method instance.

In fact, all class-loader related code that either reads or writes
class-loader data structures has to be synchronized using the monitor
of the VirtualMachine class instance.

In particular, calling _svmf_resolve_incomplete_method() without
synchronization would yield undefined results.  Furthermore, as Archie
pointer, we definitely do not want another thread to create an
instance between the:

   if (method_info->reflection_instance != NULL)
   ...

and the
  
   ...
   *(method_info->reflection_instance) = *method;

Doing otherwise would (among other things) leak memory.

Have fun!

Etienne

On Sun, Feb 09, 2003 at 09:05:22PM -0800, Archie Cobbs wrote:
> David Paul BELANGER wrote:
> > > 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.
> > 
> > Yes, I do understand that part but the link functions do acquire it.
> > I am wondering why we have this structure:
> > 
> > acquire monitor
> > .
> > .
> > .
> > link_class()
> >   (inside link_class)
> >   acquire monitor
> >   .
> >   .
> >   .
> >   release monitor
> > .
> > initialize_class
> >   acquire monitor
> >   .
> >   .
> >   release monitor
> > .
> > .
> > release monitor
> > 
> > What functions are we protecting with the external acquire monitor?
> 
> Maybe it's for the creation of the new Method reflection instance?
> The JVM must ensure that it only gets created once.
> 
> -Archie
> 
> __________________________________________________________________________
> Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/