sablevm-developer — SableVM developer mailing list

Re: [Sablevm-developer] building from CVS

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

Hi David,

You need to run:

aclocal ; libtoolize ; autoconf ; autoheader ; automake --foreign -a

It is also interesting to generate TAGS file using etags:

... # build commands
make ; make install
etags -R

To indent your code:

make indent

Etienne


On Sun, Feb 09, 2003 at 11:16:35PM -0500, David Paul BELANGER wrote:
> 
> Hello,
> 
> I'm trying to build SableVM from CVS but I'm not sure how to generate
> the configure script (last time I cheated and copy it from the
> release...).
> 
> I am not at all familiar with the autoconf/automake process.  Reading on
> the web didn't help.
> 
> I tried running autoconf and I got:
> ibou:~/tmp21/sablevm/sablevm> autoconf
> configure.ac:9: error: possibly undefined macro: AM_INIT_AUTOMAKE
>       If this token and others are legitimate, please use
>       m4_pattern_allow.
>       See the Autoconf documentation.
> configure.ac:11: error: possibly undefined macro:
> AM_CONFIG_HEADER
> configure.ac:31: error: possibly undefined macro:
> AC_DISABLE_STATIC
> configure.ac:122: error: possibly undefined macro:
> AC_LIBTOOL_DLOPEN
> configure.ac:123: error: possibly undefined macro:
> AM_PROG_LIBTOOL
> ibou:~/tmp21/sablevm/sablevm> 
> 	    
> My version of autoconf is 2.50.
> 
> My system is Debian GNU/Linux/PPC.
> 
> What commands do I need to run and in what order?
> 
> Thanks,
> David
> 
> ---
> 
> David B?langer
> 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
> 
> 
> 
> -------------------------------------------------------
> 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/

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

[Sablevm-developer] building from CVS

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

Hello,

I'm trying to build SableVM from CVS but I'm not sure how to generate
the configure script (last time I cheated and copy it from the
release...).

I am not at all familiar with the autoconf/automake process.  Reading on
the web didn't help.

I tried running autoconf and I got:
ibou:~/tmp21/sablevm/sablevm> autoconf
configure.ac:9: error: possibly undefined macro: AM_INIT_AUTOMAKE
      If this token and others are legitimate, please use
      m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:11: error: possibly undefined macro:
AM_CONFIG_HEADER
configure.ac:31: error: possibly undefined macro:
AC_DISABLE_STATIC
configure.ac:122: error: possibly undefined macro:
AC_LIBTOOL_DLOPEN
configure.ac:123: error: possibly undefined macro:
AM_PROG_LIBTOOL
ibou:~/tmp21/sablevm/sablevm>=20
	   =20
My version of autoconf is 2.50.

My system is Debian GNU/Linux/PPC.

What commands do I need to run and in what order?

Thanks,
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] reflection update

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

On Sun, Feb 09, 2003 at 12:50:15PM +0100, Grzegorz B. Prokopski wrote:
> W li?cie z nie, 09-02-2003, godz. 08:36, David Paul BELANGER pisze:=20
> > Hello,
> >=20
> > I have implemented:
> > - several reflection methods
> > - a basic Runtime.exec()
> > - ProcessImpl that implements Process's abstract methods.
> >=20
> > I have fixed some bugs in some reflection functions that were already
> > implemented.
> >=20
> > I was able to run:
> > - jUnit that uses getMethods()
> > - ant that uses getMethods() and that fork/exec to run Jikes
> Terrific!
> I was about to ask for the status.
>=20
> > I am currently checking/cleaning up code.  Patches could be made
> > available tomorrow or the day after.  The code is still *very*
> > experimental.
> I don't know how being experimental affects normal usage in this
> case (stability, bugs etc.) but if it makes it possible to run
> ANT with SableVM - I think we need it.

My goal was to get a quick working system that runs jUnit and ant.  It
is experimental in the sense that some new functionality is partially
implemented, not fully tested.  There may still be debugging code etc.
However, it should not affect the other parts of SableVM.

>=20
> > Etienne,
> > I would like to know what would be the best way to make these changes
> > available.  Send a big patch to this list, put it on the web, wait fo=
r a
> > development branch,...  Note that the new code is still under
> > development and may change frequently.
> We don't have sablevm-patches (and I am not sure that such list is
> really needed now) so I'd propose:
> 1. If the diff isn't too big (say 20-40kb max) - you can attach it
> to a mail to devel list
> 2. You can always put it somewhere on the web and give URL to it.
> If the diff is subject to frequent changes - it can be good idea to
> have date in the filename and (in the future) against what official
> release it was created (or CVS date if you work on CVS version).

The patch is posted on this web page, right at the end:
http://www.sable.mcgill.ca/~dbelan2/sablevm/hacking.html
(the patch is over 70k)

There is also a status file that says which functions have been
implemented.

Also, some functionality has been implemented in java instead of C.


> If the code is usable (it really runs ANT) - I'd like to see new
> official release, maybe even this week, even if ANT support would be
> marked "experimental".

I tested it with ant only on a small build file.  Ant users, let me know
if you run into problems.

I have been using it for some time with jUnit (that uses getMethods())
without problems.



Have fun!


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

[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 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

[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

[Sablevm-developer] JNI default search path

[Grzegorz B. P. <ga...@de...>]

Hi!

As per Debian Java Policy it's required for JVM in Debian to use
/usr/lib/jni as default search path for JNI binaries.

Some time ago there was submitted: http://bugs.debian.org/167937=20
I think I'll integrate the diff into next package upload as it's
apparently debian-specific. However I wanted to point you to this
bug in case Etienne wanted to have such feature (default JNI path)
in the main branch.

If it were so - I think the default JNI search path should be
configurable during configure stage. It wouldn't be that hard to
move the path to ./configure option. But we probably may also want
to support "none" setting which may require some more gymnastics.

It's just for your consideration

				Grzegorz B. Prokopski
--=20
Grzegorz B. Prokopski <ga...@de...>
Debian http://www.debian.org/

Re: [Sablevm-developer] reflection update

[Grzegorz B. P. <ga...@de...>]

W li=B6cie z nie, 09-02-2003, godz. 08:36, David Paul BELANGER pisze:=20
> Hello,
>=20
> I have implemented:
> - several reflection methods
> - a basic Runtime.exec()
> - ProcessImpl that implements Process's abstract methods.
>=20
> I have fixed some bugs in some reflection functions that were already
> implemented.
>=20
> I was able to run:
> - jUnit that uses getMethods()
> - ant that uses getMethods() and that fork/exec to run Jikes
Terrific!
I was about to ask for the status.

> I am currently checking/cleaning up code.  Patches could be made
> available tomorrow or the day after.  The code is still *very*
> experimental.
I don't know how being experimental affects normal usage in this
case (stability, bugs etc.) but if it makes it possible to run
ANT with SableVM - I think we need it.

> Etienne,
> I would like to know what would be the best way to make these changes
> available.  Send a big patch to this list, put it on the web, wait for a
> development branch,...  Note that the new code is still under
> development and may change frequently.
We don't have sablevm-patches (and I am not sure that such list is
really needed now) so I'd propose:
1. If the diff isn't too big (say 20-40kb max) - you can attach it
to a mail to devel list
2. You can always put it somewhere on the web and give URL to it.
If the diff is subject to frequent changes - it can be good idea to
have date in the filename and (in the future) against what official
release it was created (or CVS date if you work on CVS version).

If the code is usable (it really runs ANT) - I'd like to see new
official release, maybe even this week, even if ANT support would be
marked "experimental".

Thank you for your work David

					Grzegorz B. Prokopski
--=20
Grzegorz B. Prokopski <ga...@de...>
Debian http://www.debian.org/

[Sablevm-developer] reflection update

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

Hello,

I have implemented:
- several reflection methods
- a basic Runtime.exec()
- ProcessImpl that implements Process's abstract methods.

I have fixed some bugs in some reflection functions that were already
implemented.

I was able to run:
- jUnit that uses getMethods()
- ant that uses getMethods() and that fork/exec to run Jikes

I am currently checking/cleaning up code.  Patches could be made
available tomorrow or the day after.  The code is still *very*
experimental.

Etienne,
I would like to know what would be the best way to make these changes
available.  Send a big patch to this list, put it on the web, wait for a
development branch,...  Note that the new code is still under
development and may change frequently.


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

[Sablevm-developer] New SableVM build script

[Bruno D. <bru...@ma...>]

Hi,

	I am contributing a new (bash) build script for SableVM which is meant to 
replace both build & build-many. It has a lot of new features, including 
checking the exit status of all executed commands (so it does not go on if 
one of them fails). It is implemented using a lot of functions, so as to make 
it easy to change a particular phase. It is now also easy to add new SableVM 
configurations. 

Using the script:

'build' becomes 'build-sablevm' and 'build-many' becomes 'build-sablevm 
--vms=all'. You can also type something like build-sablevm 
--vms=inlined,direct,switch.

Also, there is no longer a dependency on the user not including the trailing 
slash after the installation path. It is stripped off if included. Try 
running the script with --help to learn more about how to use it.

Let me know if you have any specific request / suggestion.

-- 
	Bruno Dufour
	Sable Research Group
	McGill University, Montreal, Canada
	bru...@ma...

Re: [Sablevm-developer] loading/linking/... function

[Prof. E. M. G. <eti...@uq...>]

> The reason such function isn't made available is that it is a very bad 
> idea to check if a class should be initialized on every instance 
> creation.

I think I should have explained better.

To "conditionally load" a class means that you are looking up this class "by 
name". This lookup requires acquiring a global lock.  As you can imagine, 
additional global lock operations reduce the potential concurrency in your program.

I hope this helps understanding the need to "locally" cache created-class pointers.

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

Re: [Sablevm-developer] loading/linking/... function

[Prof. E. M. G. <eti...@uq...>]

David Paul BELANGER wrote:
> Hello,
> 
> I am wondering if there a high-level function in sablevm that
> given the name of a
> class, it will load/link/initialize (if necessary) then create an
> instance?

No, there isn't.  But, you might be interested to look at the implementation of 
the PREPARE_NEW instruction in instructions.m4.c which does what you are looking 
for.

The reason such function isn't made available is that it is a very bad idea to 
check if a class should be initialized on every instance creation.  You should, 
instead, remember that you have loaded/../initialized a class.

The JNI interace makes this explicit by providing "cache-able" method ids (used 
for the instance constructor).

> I did not find any and I will start implementing my own.  Let me know if
> one already exists.

Please don't implement such function.  Instead, create (e.g. load, link, 
initialize) all classes you need and cache them.

Etienne

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

[Sablevm-developer] loading/linking/... function

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

Hello,

I am wondering if there a high-level function in sablevm that
given the name of a
class, it will load/link/initialize (if necessary) then create an
instance?
ex: __new_instance("java/io/FileDescriptor", instance)

I did not find any and I will start implementing my own.  Let me know if
one already exists.


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] Where to change the makefile

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

Hello,

Another way is to set some environment variables before calling
configure.

ex:
CPPFLAGS=3D'-DPMC_P6'
export CPPFLAGS

LDFLAGS=3D'-lpmc'
export LDFLAGS

Then call ./configure.

You can do ./configure --help to see what variables affect compilation.



David



On Tue, Feb 04, 2003 at 10:07:48PM +0000, Bruno Dufour wrote:
> Hi,
>=20
> 	The makefiles get generated from their Makefile.am counterparts when y=
ou run=20
> the 'configure' script. The one you are probably looking for is=20
> sablevm-1.0.5/src/libsablevm/Makefile.am=20
>=20
> Cheers,
>=20
> --=20
> 	Bruno Dufour
> 	Sable Research Group
> 	McGill University, Montreal, Canada
> 	bru...@ma...
>=20
> On Wednesday 05 February 2003 02:57 am, Dayong Gu wrote:
> > Hello,
> > In order to use the pmc-lib I need to add oprtion "-DPMC_P6"  and  to
> > link
> > libpmc.
> > I try to change the Makefile to add them, but it seems the makefile i=
s
> > automatically regenerate
> > while call "build-many".
> > Where can I make these changes?
> >
> > Thank u!
> >
> >
> > Cheers,
> > Dayong
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See=
!
> > http://www.vasoftware.com
> > _______________________________________________
> > Sablevm-developer mailing list
> > Sab...@li...
> > https://lists.sourceforge.net/lists/listinfo/sablevm-developer
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer

--=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] Where to change the makefile

[Bruno D. <bru...@ma...>]

Hi,

	The makefiles get generated from their Makefile.am counterparts when you run 
the 'configure' script. The one you are probably looking for is 
sablevm-1.0.5/src/libsablevm/Makefile.am 

Cheers,

-- 
	Bruno Dufour
	Sable Research Group
	McGill University, Montreal, Canada
	bru...@ma...

On Wednesday 05 February 2003 02:57 am, Dayong Gu wrote:
> Hello,
> In order to use the pmc-lib I need to add oprtion "-DPMC_P6"  and  to
> link
> libpmc.
> I try to change the Makefile to add them, but it seems the makefile is
> automatically regenerate
> while call "build-many".
> Where can I make these changes?
>
> Thank u!
>
>
> Cheers,
> Dayong
>
>
>
> -------------------------------------------------------
> 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

[Sablevm-developer] Where to change the makefile

[Dayong Gu <dg...@cs...>]

Hello,
In order to use the pmc-lib I need to add oprtion "-DPMC_P6"  and  to
link
libpmc.
I try to change the Makefile to add them, but it seems the makefile is
automatically regenerate
while call "build-many".
Where can I make these changes?

Thank u!


Cheers,
Dayong

Re: [Sablevm-developer] ppc libffi

[Prof. E. M. G. <eti...@uq...>]

If I understand correctly, the problem is the way return values are handl=
ed.

Byte-sized return values are returned in a word-sized memory location.  I=
 had=20
missed this little detail in the libffi documentation.

If I understand correctly, this is not so for input arguments.  Right?

Thanks,

Etienne


David Paul BELANGER wrote:
> Etienne,
>=20
> My bug report on the problem with libffi/SableVM on the PPC architectur=
e
> as well as the reply I received may be found here:
>=20
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D173074
>=20
> I have not study/try what they say in their reply yet.
>=20
> David
>=20
> ---
>=20
> David B=E9langer
> Graduate Student
> School of Computer Science
> McGill University
> Office: MC226
>=20
> Web page:   http://www.cs.mcgill.ca/~dbelan2/
> Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3Domething 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer
>=20
> .
>=20

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

[Sablevm-developer] ppc libffi

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

Etienne,

My bug report on the problem with libffi/SableVM on the PPC architecture
as well as the reply I received may be found here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D173074

I have not study/try what they say in their reply yet.

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] Question about JNI methods

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

Prof. Etienne M. Gagnon wrote:
> Doesn't the JVM spec mandates to search super interfaces and classes?
> I know it is surprizing, but that is so, even for "static" methods
> and fields!!!

Yes, that is surprising..

So you're right when talking about resolving a CONSTANT_Fieldref
in a class file.. as for the JNI GetStaticFieldID() method, the spec
doesn't really say, but I guess it makes the most sense to follow the
same semantics as with CONSTANT_Fieldref... OK :-)

Thanks,
-Archie

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

Re: [Sablevm-developer] Questions about ClassLoaders and reflection

[Prof. E. M. G. <eti...@uq...>]

Archie Cobbs wrote:
> Some "theoretical" questions... :-)
> 
> Couldn't instances of the classes Class, Method, Field, and Constructor
> be stored in the per-ClassLoader memory area?

It could theoretically be so, but this means that we maintain a non-uniform Java 
heap.  SableVM's current brain-dead copying collector is totally uniform; no 
pinned objects, no special heap areas, no special anything.

Of course, when you start implementing a generational collector, then it makes 
kind of sense to start managing class-loader specific Java heaps.  In fact, the 
nice thing is that this special kind of generation needs no be garbage collected 
ever (other than a complete free of all of the class-loader related memory, on 
class unloading).

> 
> Of course the GC would have to know not to move them, but overall
> this might be more efficient for applications that use reflection
> heavily.
> 
> Also: it doesn't appear that SableVM supports unloading ClassLoader's.
> Is that correct?

Yes it is.  You have to analyze the heap and static areas before deciding to 
unload a complete class loader + all its resources.  When you start thinking 
about it seriously, you quickly discover that it has to be done very carefully. 
  I think we should get the rest of the VM more robust before getting into this 
part.

> What would be required to do this? Seems like you
> could do it simply by adding a ClassLoader.finalize() native method
> which just free'd the per-ClassLoader memory blob and unloaded any
> native libraries.
> 
> Hmm, talking to myself... java.lang.Object does not contain any
> field that references the object's Class object (nor should it for
> efficiency reasons).  Therefore, Class objects must be referenced
> internally by the VM to be kept alive. However, since in SableVM
> these references must be global, the Class object can never be GC'd,
> and therefore it's ClassLoader object could never be GC'd, and so
> ClassLoaders could never be unloaded.
> 
> Other "implicit" references include Class -> ClassLoader,
> Class -> Class (superclass or superinterface), etc...
> 
> So, keeping stuff alive properly is more complicated...
> 
> Also: does SableVM ever run Object.finalize()? I don't see where it does.

No.  Now, this is something we should fix, but it is not critical; the VM spec 
does not garantee that finalize() be executed.  Now, I know we cheat when we 
actually reuse a dead object's memory area to store new objects, but 
theoretically, it is correct.  Now, the fun thing will be to also implement 
weak, soft, and phantom, while also respecting the life cycle of finalized 
objects;-) [Just a lot of code to add to GC].

Etienne

> 
> Thanks,
> -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/

Re: [Sablevm-developer] Question about JNI methods

[Prof. E. M. G. <eti...@uq...>]

Doesn't the JVM spec mandates to search super interfaces and classes?  I know it 
is surprizing, but that is so, even for "static" methods and fields!!!

Unless I'm wrong?

Etienne

Archie Cobbs wrote:
> Question about GetStaticFieldID() and GetStaticMethodID().
> 
> These JNI functions call _svmf_resolve_field() and _svmf_resolve_method()
> (respectively) in order to find the field or method. While this
> makes sense for GetFieldID() and GetMethodID(), this seems incorrect
> for GetStaticFieldID() and GetStaticMethodID(), as we don't want
> to look for the field or method in any superclass or interface...
> 
> ??
> 
> Thanks,
> -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/

[Sablevm-developer] Questions about ClassLoaders and reflection

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

Some "theoretical" questions... :-)

Couldn't instances of the classes Class, Method, Field, and Constructor
be stored in the per-ClassLoader memory area?

Of course the GC would have to know not to move them, but overall
this might be more efficient for applications that use reflection
heavily.

Also: it doesn't appear that SableVM supports unloading ClassLoader's.
Is that correct? What would be required to do this? Seems like you
could do it simply by adding a ClassLoader.finalize() native method
which just free'd the per-ClassLoader memory blob and unloaded any
native libraries.

Hmm, talking to myself... java.lang.Object does not contain any
field that references the object's Class object (nor should it for
efficiency reasons).  Therefore, Class objects must be referenced
internally by the VM to be kept alive. However, since in SableVM
these references must be global, the Class object can never be GC'd,
and therefore it's ClassLoader object could never be GC'd, and so
ClassLoaders could never be unloaded.

Other "implicit" references include Class -> ClassLoader,
Class -> Class (superclass or superinterface), etc...

So, keeping stuff alive properly is more complicated...

Also: does SableVM ever run Object.finalize()? I don't see where it does.

Thanks,
-Archie

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

[Sablevm-developer] Question about JNI methods

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

Question about GetStaticFieldID() and GetStaticMethodID().

These JNI functions call _svmf_resolve_field() and _svmf_resolve_method()
(respectively) in order to find the field or method. While this
makes sense for GetFieldID() and GetMethodID(), this seems incorrect
for GetStaticFieldID() and GetStaticMethodID(), as we don't want
to look for the field or method in any superclass or interface...

??

Thanks,
-Archie

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

Re: [Sablevm-developer] reflection methods

[Grzegorz B. P. <ga...@de...>]

W li=B6cie z nie, 26-01-2003, godz. 16:55, David Paul BELANGER pisze:=20
> Hello,
>=20
> I volunteered to help implement the native methods in the reflection
> classes (java.lang.Class and classes in java.lang.reflect).
> These include methods such as Class.getMethods() that have
> been asked a few times on this list.
Great! I think having these methods working is one of the
"to be or not to be" issues for SableVM.
The more important your work is then.

> My short term goal is to implement enough methods to run Ant and JUnit
> as soon as possible.
:-)

> I have a partially working getMethods().  I will made my code public as
> soon as a have a reasonable set of working functions.
I am very curious how these implementations will look like.

Best wishes

				Grzegorz B. Prokopski
--=20
Grzegorz B. Prokopski <ga...@de...>
Debian http://www.debian.org/