Re: classpath initialization
In Jaos, the ClassLoader is loaded but not really used (I'm still stuck with classpath 0.5) because I have my own native implementation which overrides the calls to Java's classloader in Class.fromName(). I'm currently upgrading my implementation to work with 0.6 by moving all the native stuff into the VM classes, but haven't got that far yet (it's a lot of work!) -Patrik > For comparison, Wonka's explicit class initialisation looks something like > this: > ** 1) load class java/lang/Object. > ** 2) load java/lang/Cloneable, java/lang/Serializable, > java/lang/Throwable. > ** 3) create clazz_Array. clazz_Array acts like clazzObject but has > ** a modified method table and a modified interfaces table. > ** It overrides the clone method of java/lang/Object and adds two > ** new interfaces: Cloneable and Serializable. > ** (We need to do this before any subclasses of Throwable are loaded, > ** in order to ensure that they are marked CLAZZ_IS_THROWABLE). > ** 4) load java/lang/Class, java/lang/ClassLoader, java/lang/Thread, > ** java/lang/ThreadGroup, and java/lang/ref/Reference. > ** 5) load all the classes mentioned in core-classes.in. > ** 6) For each primitive class xxx, create: > ** -An instance Class_xxx of class java/lang/Class, linked to > **a w_Clazz structure (clazz_xxx). > **The name associated with the Class instance is "xxx.class". > ** -Entries in the array atype2clazz[], which is indexed by P_xxx. > > Step 5) is needed because we need to create explicit relationships between C > and Java constructs for quite a large number of classes, which Patrik doesn't > need to do because he's using Oberon. I guess that's also why he doesn't need > to explicitly load ClassLoader; we need to do that because of all the > behind-the-scenes stuff needed to implement class loading according to the > JVM spec. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath initialization
For comparison, Wonka's explicit class initialisation looks something like this: ** 1) load class java/lang/Object. ** 2) load java/lang/Cloneable, java/lang/Serializable, java/lang/Throwable. ** 3) create clazz_Array. clazz_Array acts like clazzObject but has ** a modified method table and a modified interfaces table. ** It overrides the clone method of java/lang/Object and adds two ** new interfaces: Cloneable and Serializable. ** (We need to do this before any subclasses of Throwable are loaded, ** in order to ensure that they are marked CLAZZ_IS_THROWABLE). ** 4) load java/lang/Class, java/lang/ClassLoader, java/lang/Thread, ** java/lang/ThreadGroup, and java/lang/ref/Reference. ** 5) load all the classes mentioned in core-classes.in. ** 6) For each primitive class xxx, create: ** -An instance Class_xxx of class java/lang/Class, linked to **a w_Clazz structure (clazz_xxx). **The name associated with the Class instance is "xxx.class". ** -Entries in the array atype2clazz[], which is indexed by P_xxx. Step 5) is needed because we need to create explicit relationships between C and Java constructs for quite a large number of classes, which Patrik doesn't need to do because he's using Oberon. I guess that's also why he doesn't need to explicitly load ClassLoader; we need to do that because of all the behind-the-scenes stuff needed to implement class loading according to the JVM spec. Best wishes Chris On Monday 20 October 2003 22:03, Patrik Reali wrote: > Hi! > > Initializing a JVM is quite a complicated thing. Many problems depend on > which class you first initialize, because this could cause unexpected > dependecies to pop up. > > Jaos doesn't suffer from the problem you descrive, because it doesn't use > the external libraries or JNI: Oberon is rather close to Java, and the > objects can be directly accessed from both languages without fear of > breaking the type system or confusing the garbage collector. > > I also had my share of problems with the system properties, because they > are hard-coded in the libraries and I didn't realize it at once. > Furthermore, the properties and java.io assume an unix-like filesystem, > which Oberon doesn't have: we don't have directories, only mounts. > > In Jaos, I explicitely initialize a few classes during bootstrap (this are > only the explicit calls, other classes may be automatically initialized as > side effect, and in fact about 80 are!). This code relies on classpath 0.5 > (I'm not through updating yet). > > 1. String > 2. Throwable > 3. StackTraceElement > 4. VMThrowable > 5. Thread > 6. ThreadGroup > 7. System > > This may look strange, but > > 1. String is implicitely used everywhere, because the string constants are > instances of this class; according to the spec, allocating an instance of a > class causes the class to be initialized. (I could avoid this, but then I > would have to protect every access to the string methods with a check to > launch initialization; Strings are already slow enough in Jaos). > > 2. Throwable / StackTraceElement / VMThrowable: I must allocate them when > the VM is launched: loading them on-demand (at the first exception) is > already too late, because the VM is already processing an exception (in > Oberon this is done with a software interrupt) and loading reads from the > disc (causing more interrupts), but the kernel doesn't allow to interrupt > handler to cause other interrupts. > > 3. Thread / ThreadGroup must be initialized, because every java program is > executed in a java thread; Jaos creates such a thread for the execution of > a java program. > > This remarks (in particular 2 and 3) are quite Jaos specific. > > This won't probably solve your problem, but may give you some insight about > the various problems encountered during the initialization phase. > > -Patrik > > Patrik Reali > http://www.reali.ch/~patrik/ > http://www.oberon.ethz.ch/jaos > > > - Original Message - > From: "Joseph Wenninger" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, October 14, 2003 9:33 PM > Subject: classpath initialization > > > Hi > > > > I'm trying to use an unmodified classpath (0.06). I already have > > something working with a modified one. > > > > My problem is that the call stack during initialization of the System > > class I looks something like > > > > LOG: called: java/lang/System.()V() > > LOG: called: > > java/lang/System.loadLibrary(Ljava/lang/String;)V(405c8488) > > LOG: called: java/lang/Runtime.
Re: classpath initialization
Hi! Initializing a JVM is quite a complicated thing. Many problems depend on which class you first initialize, because this could cause unexpected dependecies to pop up. Jaos doesn't suffer from the problem you descrive, because it doesn't use the external libraries or JNI: Oberon is rather close to Java, and the objects can be directly accessed from both languages without fear of breaking the type system or confusing the garbage collector. I also had my share of problems with the system properties, because they are hard-coded in the libraries and I didn't realize it at once. Furthermore, the properties and java.io assume an unix-like filesystem, which Oberon doesn't have: we don't have directories, only mounts. In Jaos, I explicitely initialize a few classes during bootstrap (this are only the explicit calls, other classes may be automatically initialized as side effect, and in fact about 80 are!). This code relies on classpath 0.5 (I'm not through updating yet). 1. String 2. Throwable 3. StackTraceElement 4. VMThrowable 5. Thread 6. ThreadGroup 7. System This may look strange, but 1. String is implicitely used everywhere, because the string constants are instances of this class; according to the spec, allocating an instance of a class causes the class to be initialized. (I could avoid this, but then I would have to protect every access to the string methods with a check to launch initialization; Strings are already slow enough in Jaos). 2. Throwable / StackTraceElement / VMThrowable: I must allocate them when the VM is launched: loading them on-demand (at the first exception) is already too late, because the VM is already processing an exception (in Oberon this is done with a software interrupt) and loading reads from the disc (causing more interrupts), but the kernel doesn't allow to interrupt handler to cause other interrupts. 3. Thread / ThreadGroup must be initialized, because every java program is executed in a java thread; Jaos creates such a thread for the execution of a java program. This remarks (in particular 2 and 3) are quite Jaos specific. This won't probably solve your problem, but may give you some insight about the various problems encountered during the initialization phase. -Patrik Patrik Reali http://www.reali.ch/~patrik/ http://www.oberon.ethz.ch/jaos - Original Message - From: "Joseph Wenninger" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 14, 2003 9:33 PM Subject: classpath initialization > Hi > > I'm trying to use an unmodified classpath (0.06). I already have > something working with a modified one. > > My problem is that the call stack during initialization of the System > class I looks something like > > LOG: called: java/lang/System.()V() > LOG: called: > java/lang/System.loadLibrary(Ljava/lang/String;)V(405c8488) > LOG: called: java/lang/Runtime.getRuntime()Ljava/lang/Runtime;() > LOG: finished: > java/lang/Runtime.getRuntime()Ljava/lang/Runtime;->0x8420fd8 > LOG: called: > java/lang/Runtime.loadLibrary(Ljava/lang/String;)V(8420fd8, 405c8488) > LOG: called: > java/lang/VMSecurityManager.currentClassLoader()Ljava/lang/ClassLoader;() > LOG: called: java/lang/ClassLoader.()V() > LOG: compiler_addinitclass: java/lang/VMClassLoader > LOG: called: > java/lang/VMClassLoader.getSystemClassLoader()Ljava/lang/ClassLoader;() > LOG: called: > java/lang/System.getProperty(Ljava/lang/String;Ljava/lang/String;)Ljava/lang /String;(405cb500, 405cb578) > ()V > The last line causes an exception, since the static member properties > isn't initialized yet. Did anybody else encounter such a problem ? I'm > not sure if that it is a vm bug or a compiler problem or something that > I miss > > Kind regards > Joseph Wenninger > > > > ___ > Classpath mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/classpath > > ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RE: classpath initialization
Joseph, > My problem is that the call stack during initialization of > the System class I looks something like ... > The last line causes an exception, since the static member > properties isn't initialized yet. Initialization is quite tricky. Basically your VMClassloader is making assumptions about the initialization state of the system that are not valid in the default initialization sequence. We encountered a similar problem (and others). If we tried to create a String from a byte[] we needed the EncodingManager which needed to access a system property but System had not reached a point in initialization where you could call getProperty. I actually posted an email to the list about this a couple of weeks ago - which I've attached below. We had to change the way System.java behaved during initialization. (Somewhat related we also have to take pains to avoid referencing String literals early in the VM startup process because they can't be interned at that point.) David Holmes -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Holmes Sent: Thursday, 25 September 2003 2:21 PM To: classpath Subject: File encodings and initialization sequence Just wanted to share experiences with the initialization sequence and trying to resolve the character encoding problem. To fill in various system properties in Runtime we use native code to get C char arrays with output from things like uname, cwd etc. These are returned as Java byte arrays and have to be converted to Java Strings. The correct way to do this seemed to be to use the String(byte[]) constructor and ensure the corrected decoder was used. But this wasn't possible because the EncodingManager. uses System.getProperty and that would be called before System. had actually initialized its properties object. Hence we'd get a NullPointerException. To fix this Runtime now forces System to use it's properties object until System. reaches the point were it clones runtime's properties object. Before I set any system properties I now extract the default character set name, acquired via native code, and use that to set the file.encoding property. Then I set all the encoding alias properties in case the default charset name is actually an alias. After that I can construct Strings from byte[] using the right decoding. I'm curious how others have dealt with this issue. I'm no expert on character-set/locale/internationalization issues. Related to this problem, I also found out that any exception that occurs prior to the point where System clones the runtime properties will cause recursive exceptions because Throwable. also uses System.getProperty, which will throw NPE. I'd be tempted to have any static initialization code that needs a system property to read it direct from Runtime.properties - though of course that only works for classes in java.lang. Cheers, David Holmes ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
classpath initialization
Hi I'm trying to use an unmodified classpath (0.06). I already have something working with a modified one. My problem is that the call stack during initialization of the System class I looks something like LOG: called: java/lang/System.()V() LOG: called: java/lang/System.loadLibrary(Ljava/lang/String;)V(405c8488) LOG: called: java/lang/Runtime.getRuntime()Ljava/lang/Runtime;() LOG: finished: java/lang/Runtime.getRuntime()Ljava/lang/Runtime;->0x8420fd8 LOG: called: java/lang/Runtime.loadLibrary(Ljava/lang/String;)V(8420fd8, 405c8488) LOG: called: java/lang/VMSecurityManager.currentClassLoader()Ljava/lang/ClassLoader;() LOG: called: java/lang/ClassLoader.()V() LOG: compiler_addinitclass: java/lang/VMClassLoader LOG: called: java/lang/VMClassLoader.getSystemClassLoader()Ljava/lang/ClassLoader;() LOG: called: java/lang/System.getProperty(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;(405cb500, 405cb578) ()Vhttp://mail.gnu.org/mailman/listinfo/classpath
