Re: String/Hashtable boostrapping (again)

[Etienne M. Gagnon]

Patrick Doyle wrote:

> However, I don't think that's the central issue.  There really is a
> fundamental initialization problem here:
> ...
> As classpath stands, I can't see any way to do this correctly.  Am I
> missing it?  What is the sequence of events which causes these things to
> be initialized properly?
>
> Then, assuming there is such a correct sequence, doesn't this code still
> seem somewhat obscure?  Should it be rewritten so as not to rely so
> heavily on Java's precise initialization semantics, just for clarity?


I think you are expecting too much from the class libraries (Classpath). 
 It is OK for Classpath to have "recursive" dependecies, as long as 
their expected behavior is consistent with the Java/JVM semantics except 
while bootstrapping the VM.

It is the task of the VM to bootstrap itslef to some stable state where 
it can start fulfilling the complete Java/JVM semantics, and it is not 
the class libraries task to anticipate the needs of the various VMs for 
minor/easily resolved issues like bootstrapping the String class.  We 
certainly do not want to add any overhead to String.intern(), or make 
the String/Hastable code overly complex, just for the sake of 
simplifying the initial VM bootstrapping.

I say this because you might have to face many other bootstrapping 
problems in your VM.  For example, imagine that you wanted to support 
class loading out of .jar files, but you wanted to do it using 
java.util.zip classes (why rewrite the whole thing in C/C++, when you 
can have nice and robust code for it written in Java?).  You really 
don't want to bother the java.util.zip.* developers with your VM 
initialization/class loading problems to make this possible, instead, 
you want to handle these problems internally in you VM, keeping a nice 
separation of concerns between the libraries and the VM (as much as is 
possible).

As I said in another message, handling bootstrapping issues is not 
difficult.  Yes it requires some care, but it is easily achieved with a 
special bootstrapping mode in your VM.  While in bootstrapping mode, you 
can decide not to fullfill all of the Java/JVM semantics, for various 
reasons.  One of such reasons is the impossibility to fullfill the 
semantics, e.g.: during initialization, a "ClassFormatError" is detected 
while parsing the "ClassFormatError.class" file...

I hope this will help you with your VM design.

Etienne
--
+--------------------------------------------------------------------+
| Étienne M. Gagnon                    mailto:address@hidden |
| Professeur adjoint            Téléphone: (514) 987-3000 poste 8215 |
| Bureau: PK-4930                        Télécopieur: (514) 987-8477 |
| Département d'informatique, UQÀM          http://www.info.uqam.ca/ |
| Auteur de SableVM                          http://www.sablevm.org/ |
| et de SableCC                              http://www.sablecc.org/ |
+--------------------------------------------------------------------+
| Etienne M. Gagnon                    mailto:address@hidden |
| Assistant Professor                Phone: (514) 987-3000 ext. 8215 |
| Office: PK-4930                                Fax: (514) 987-8477 |
| Department of Computer Science, UQAM      http://www.info.uqam.ca/ |
| Author of SableVM                          http://www.sablevm.org/ |
| and SableCC                                http://www.sablecc.org/ |
+--------------------------------------------------------------------+