sablevm-developer

[Sablevm-developer] More on bootstrapping

[Ian R. <ir...@cs...>]

Hi,

I'm free to modify java/lang/Runtime all I want as it is a VM specific
file :-) It seems badly written too as it half uses ':' as a path
seperator and half uses File.pathSeperatorChar. The System.setProperty
-> Hashtable.hash -> Math.<clinit> -> System.loadLibrary ->
Runtime.loadLibrary -> ... bootstrapping problem seems to be resolved by
modifying Runtime.Runtime too :-) Anyway my modifications are attached
as a patch. I'll commit them if anyone wants.

Ta,

Ian

Re: [Sablevm-developer] More on bootstrapping

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

Hi Ian,

Just go ahead and check it in.  We certainly don't want system dependant stuff in there.

Etienne

On Thu, Sep 20, 2001 at 06:57:54PM +0000, Ian Rogers wrote:
> Hi,
> 
> I'm free to modify java/lang/Runtime all I want as it is a VM specific
> file :-) It seems badly written too as it half uses ':' as a path
> seperator and half uses File.pathSeperatorChar. The System.setProperty
> -> Hashtable.hash -> Math.<clinit> -> System.loadLibrary ->
> Runtime.loadLibrary -> ... bootstrapping problem seems to be resolved by
> modifying Runtime.Runtime too :-) Anyway my modifications are attached
> as a patch. I'll commit them if anyone wants.
> 
> Ta,
> 
> Ian
> Index: sablepath-classes/src/java/lang/Runtime.java
> ===================================================================
> RCS file: /cvsroot/sablevm/sablepath-classes/src/java/lang/Runtime.java,v
> retrieving revision 1.1.1.2
> diff -r1.1.1.2 Runtime.java
> 45a46,47
> > 		char pathSeparatorChar = ':';
> > 
> 55c57
> < 			if(path.charAt(i) == ':')
> ---
> > 			if(path.charAt(i) == pathSeparatorChar)
> 63c65
> < 			int next = path.indexOf(File.pathSeparatorChar,current);
> ---
> > 			int next = path.indexOf(pathSeparatorChar,current);
> 164a167
> > 	    


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

Re: [Sablevm-developer] More on bootstrapping

[Ian R. <ir...@cs...>]

Hi Etienne,

> Just go ahead and check it in.  We certainly don't want system dependant stuff in there.

Runtime.java is VM dependent file you've pulled in from vm/reference.
The patch is UNIX dependent and removes the bootstrapping problem. I'm
unclear how you can remove the UNIX dependence without causing the
bootstrapping problem. I'll check the file in for now as it is at least
working on UNIX rather than nothing as before.

Ian

Re: [Sablevm-developer] More on bootstrapping

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

Ian Rogers wrote:

> Runtime.java is VM dependent file you've pulled in from vm/reference.
> The patch is UNIX dependent and removes the bootstrapping problem. I'm
> unclear how you can remove the UNIX dependence without causing the
> bootstrapping problem. I'll check the file in for now as it is at least
> working on UNIX rather than nothing as before.


One of the reasons I have moved the vm/* classes with the remaining 
classes is that I have this long term objective of specifying even these 
core classes in a VM independent way, as much as possible, leaving as 
little as possible native calls back to the VM to gather VM specific 
information.  I think that this is feasible, at least for "dynamic" 
systems. (Might cause problems for static compilers like GCJ).

The result would be a lean and hopefully well specified VM interface.

I can dream... ;)


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

Re: [Sablevm-developer] More on bootstrapping

[John L. <je...@pi...>]

> I'm free to modify java/lang/Runtime all I want as it is a VM specific
> file :-) It seems badly written too as it half uses ':' as a path
> seperator and half uses File.pathSeperatorChar. The System.setProperty
> -> Hashtable.hash -> Math.<clinit> -> System.loadLibrary ->
> Runtime.loadLibrary -> ... bootstrapping problem seems to be resolved by
> modifying Runtime.Runtime too :-) Anyway my modifications are attached
> as a patch. I'll commit them if anyone wants.
> 
> Ta,
> 
> Ian
> Index: sablepath-classes/src/java/lang/Runtime.java
> ===================================================================
> RCS file: /cvsroot/sablevm/sablepath-classes/src/java/lang/Runtime.java,v
> retrieving revision 1.1.1.2
> diff -r1.1.1.2 Runtime.java
> 45a46,47
> > 		char pathSeparatorChar = ':';
> > 
> 55c57
> < 			if(path.charAt(i) == ':')
> ---
> > 			if(path.charAt(i) == pathSeparatorChar)
> 63c65
> < 			int next = path.indexOf(File.pathSeparatorChar,current);
> ---
> > 			int next = path.indexOf(pathSeparatorChar,current);
> 164a167

If I understand it correctly, you're now hardcoding the separator in your Runtime file?

John Leuner

Re: [Sablevm-developer] More on bootstrapping

[Ian R. <ir...@cs...>]

Hi John,

> If I understand it correctly, you're now hardcoding the separator in your Runtime file?

The original Runtime file had a mix of hardcoded ':'s and
File.pathSeparatorChar. The use of File led to Runtime being re-entered
when it hadn't been statically initialised. To stop this I hardcoded the
pathSeparatorChar in Runtime.Runtime to ':'. I would like to use a
property to read the path seperator character but it's not obvious how
to without bootstrapping problems. One ugly solution would be to have a
native getPathSeperatorChar method. Anyhow, thoughts and comments
appreciated.

Ian

Re: [Sablevm-developer] More on bootstrapping

[John L. <je...@pi...>]

> > If I understand it correctly, you're now hardcoding the separator in your Runtime file?
> 
> The original Runtime file had a mix of hardcoded ':'s and
> File.pathSeparatorChar. The use of File led to Runtime being re-entered
> when it hadn't been statically initialised. To stop this I hardcoded the
> pathSeparatorChar in Runtime.Runtime to ':'. I would like to use a
> property to read the path seperator character but it's not obvious how
> to without bootstrapping problems. One ugly solution would be to have a
> native getPathSeperatorChar method. Anyhow, thoughts and comments
> appreciated.

Just checking.

A native method might be a solution, it's not hard at all.

You might find (later on), that reducing the depth of the call stack during initialization of the class libraries can ease debugging.

(Which is why removing circular dependencies is a good thing).

John Leuner