Hello
I've found a flaw in my logic (while trying to go to sleep this early in the
morning) down below because it is Platform.FILE_SYSTEM which has to be
uninitialized while I've written that it is Platform.NETWORK_SYSTEM. I think
I've just got line lumbers shifted somehow due to attempts to add debug
prints into classlib.
I am still sure that my idea about uninitialized constants in bootstrap is
correct. It is not the first time I see this.
On Wednesday 05 July 2006 04:00 Gregory Shimansky wrote:
> On Tuesday 04 July 2006 14:00 Alexey Varlamov wrote:
> > > > This is AFAIK something that drlvm doesn't have in kernel classes at
> > > > the moment. I think the correct way to fix the problem would be to
> > > > add one and invoke it somehow... but I don't really know the
> > > > subtleties of classloader hierarchy so I am not sure how and when it
> > > > should be invoked.
> > >
> > > Hmm, yes that is something that needs fixing.
> >
> > I volunteer to look into this.
>
> It looks like the most recent changes to classlib in file operations
> created an unresolved bootstrap dependency if security/ directory with its
> rules and policies is copied from classlib's lib/ to drlvm lib/ directory.
> In this case security cannot initialize correctly because the field
> FileInputStream.fileSystem is null at the moment when it is needed. Stack
> trace looks like this:
>
> ****** STACK DUMP: ************
> java/io/FileInputStream.<init>(Ljava/io/File;)V (FileInputStream.java:66)
> java/security/Security$1.run()Ljava/lang/Object; (Security.java:113)
> java/security/AccessController.doPrivilegedImpl(Ljava/security/PrivilegedAc
>tion;Ljava/security/AccessControlContext;)Ljava/lang/Object; (NULL:-1)
> java/security/AccessController.doPrivileged(Ljava/security/PrivilegedAction
>;)Ljava/lang/Object; (NULL:-1)
> java/security/Security.<clinit>()V (Security.java:116)
> org/apache/harmony/security/fortress/PolicyUtils$SecurityPropertyAccessor.r
>un()Ljava/lang/String; (PolicyUtils.java:148)
> org/apache/harmony/security/fortress/PolicyUtils$SecurityPropertyAccessor.r
>un()Ljava/lang/Object; (PolicyUtils.java:127)
> java/security/AccessController.doPrivilegedImpl(Ljava/security/PrivilegedAc
>tion;Ljava/security/AccessControlContext;)Ljava/lang/Object; (NULL:-1)
> java/security/AccessController.doPrivileged(Ljava/security/PrivilegedAction
>;)Ljava/lang/Object; (NULL:-1)
> java/security/Policy.getDefaultProvider()Ljava/security/Policy;
> (Policy.java:150)
> java/security/Policy.getAccessiblePolicy()Ljava/security/Policy;
> (Policy.java:195)
> java/security/Policy.getPolicy()Ljava/security/Policy; (Policy.java:131)
> java/lang/ClassLoader.<clinit>()V (NULL:-1)
> java/lang/Class.desiredAssertionStatus()Z (NULL:-1)
> java/util/HashMap.<clinit>()V (HashMap.java:27)
> org/apache/harmony/luni/platform/AdapterManager.<init>()V
> (AdapterManager.java:34)
> org/apache/harmony/luni/platform/Platform.<clinit>()V (Platform.java:34)
> java/io/FileOutputStream.<init>(Ljava/io/FileDescriptor;)V
> (FileOutputStream.java:119)
> java/lang/System.createErr()Ljava/io/PrintStream; (NULL:-1)
> java/lang/System.<clinit>()V (NULL:-1)
> java/lang/Thread.<init>(Ljava/lang/ThreadGroup;Ljava/lang/Runnable;Ljava/la
>ng/String;J)V (NULL:-1)
> java/lang/Thread.<init>()V (NULL:-1)
>
> At first I was curious as to why FileInputStream.<clinit> is not in the
> stack, but I did bytecode dump and found that Sun's javac 1.5 optimized
> <init> methods to include <clinit> code into them. So it included line
>
> private IFileSystem fileSystem = Platform.getFileSystem();
>
> into constructor's code and so the value of IFileSystem FILE_SYSTEM from
> Platform was returned. But since Platform.<clinit> is clearly in the stack,
> Platform's <clinit> was not finished yet by that time. Dumping bytecode for
> compiled Platform shows that line 34 is really the assignment of constant
> NETWORK_SYSTEM which turns out to be null later down the stack.
>
> This is a quite fundamental problem with classlib's bootstrap and we don't
> have any defined bootstrap sequence. When something is initialized in
> <clinit> there is no way to be 100% sure it is really initialized in many
> classes which are commonly used because <clinit> is called only once and
> bootstrap recursion may get to call some methods of a class before <clinit>
> actually completes. The workaround for this is instead of using
>
> Whatever WHATEVER1 = Something.something();
> or
>
> Whatever WHATEVER2 = new Whatever();
>
> do the following
>
> method() {
> if (WHATEVER1 == null)
> WHATEVER1 = Something.something();
>
> if (WHATEVER2 == null)
> WHATEVER2 = new Whatever();
> }
>
> but this is ugly, inefficient and my in theory turn classlib bootstrap into
> infinite recursion.
>
> I don't know a general solution for this. The order of class resolution,
> java compiler optimizations and other factors may affect the bootstrap
> sequence.
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
