You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/05/01 03:38:02 UTC
[classlib] gnuclasspathadapter -- current status on getting specJVM98 to run
A new zip file has been uploaded to JIRA Harmony-318.
Current status:
The _209_db benchmark from specjvm98 initializes but fails to
complete. The current roadblock is opening the database files. There
may be a problem with absolute and relative path names.
System.out.println() now works. This is finally allowing printf-style
debug statements to be sprinkled in Java code. This is a big
improvement over the previous debug facility (looking at raw Java heap
memory using gdb.)
There was an unexpected and surprising parsing problem when running
_209_db on JCHEVM. The procedure called, _jc_parse_classfile(), does
some basic verification of a class file. In specific, it verifies
that a class with the ACC_INTERFACE attribute set also has the
ACC_ABSTRACT bit set. It turns out that _209_db has an interface
without the abstract bit set. _209_db will run without warning or
error on a product JVM but throws a "ClassFormatError" on JCHEVM. The
temporary patch is to comment out JCHEVM code that throws the
ClassFormatError. This problem needs further investigation.
Another problem is that JCHEVM seems to throw a fatal exception during
load time if the code being loaded refers to a class that is nowhere
to be found. I think the JVM Spec says this exception should be
delayed until execution time. The specific problem is that _209_db
code refers to AWT classes. Even though _209_db is run with the
console configuration, when the classes load they cause JCHEVM to
attempt to load AWT classes that can't be found. The workaround is
really ugly -- comment out the AWT code in the spec benchmarks.
Java.lang.System.getEncoding() – the code is not correct but does not
appear to be a roadblock currently. The encoding issue kept coming up
during debug for some reason. This needs help from someone who really
understands JVM language encoding.
Java.lang.String has some very sneaky incomplete methods in it! Hours
were spent looking at the interpreter's call stack to discover that
the method String.print(String) was setting the string to be printed
to null. Since this is in the direct path of a "System.out.println()"
it was impossible to put debug print statements in the source code to
speed up debugging. Lots of time spent digging throught
NullPointerExceptions.
Basic Java.io.File functionality now works. Virtually all the
modifications were to the native methods that support
java.io.File.java. While the goal is full compliance with Harmony
Classlib porting layer, temporary shortcuts were taken. In other
words, the native methods were connected directly to POSIX I/O APIs
instead of Harmony porting layer.
Let me know if you have questions.
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] gnuclasspathadapter -- current status on getting specJVM98
to run
Posted by Geir Magnusson Jr <ge...@pobox.com>.
excellent :)
Weldon Washburn wrote:
> A new zip file has been uploaded to JIRA Harmony-318.
>
> Current status:
>
> The _209_db benchmark from specjvm98 initializes but fails to
> complete. The current roadblock is opening the database files. There
> may be a problem with absolute and relative path names.
> System.out.println() now works. This is finally allowing printf-style
> debug statements to be sprinkled in Java code. This is a big
> improvement over the previous debug facility (looking at raw Java heap
> memory using gdb.)
>
> There was an unexpected and surprising parsing problem when running
> _209_db on JCHEVM. The procedure called, _jc_parse_classfile(), does
> some basic verification of a class file. In specific, it verifies
> that a class with the ACC_INTERFACE attribute set also has the
> ACC_ABSTRACT bit set. It turns out that _209_db has an interface
> without the abstract bit set. _209_db will run without warning or
> error on a product JVM but throws a "ClassFormatError" on JCHEVM. The
> temporary patch is to comment out JCHEVM code that throws the
> ClassFormatError. This problem needs further investigation.
>
> Another problem is that JCHEVM seems to throw a fatal exception during
> load time if the code being loaded refers to a class that is nowhere
> to be found. I think the JVM Spec says this exception should be
> delayed until execution time. The specific problem is that _209_db
> code refers to AWT classes. Even though _209_db is run with the
> console configuration, when the classes load they cause JCHEVM to
> attempt to load AWT classes that can't be found. The workaround is
> really ugly -- comment out the AWT code in the spec benchmarks.
>
> Java.lang.System.getEncoding() – the code is not correct but does not
> appear to be a roadblock currently. The encoding issue kept coming up
> during debug for some reason. This needs help from someone who really
> understands JVM language encoding.
>
> Java.lang.String has some very sneaky incomplete methods in it! Hours
> were spent looking at the interpreter's call stack to discover that
> the method String.print(String) was setting the string to be printed
> to null. Since this is in the direct path of a "System.out.println()"
> it was impossible to put debug print statements in the source code to
> speed up debugging. Lots of time spent digging throught
> NullPointerExceptions.
>
> Basic Java.io.File functionality now works. Virtually all the
> modifications were to the native methods that support
> java.io.File.java. While the goal is full compliance with Harmony
> Classlib porting layer, temporary shortcuts were taken. In other
> words, the native methods were connected directly to POSIX I/O APIs
> instead of Harmony porting layer.
>
> Let me know if you have questions.
>
> --
> Weldon Washburn
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] gnuclasspathadapter -- current status on getting specJVM98
to run
Posted by Archie Cobbs <ar...@dellroad.org>.
Weldon Washburn wrote:
> Good idea. I will try to look at mauve soon. I don't know anything
> about it. Do you know if there there any Apache license compatibility
> issues?
Not unless you're planning to resell it or something... :-)
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] gnuclasspathadapter -- current status on getting specJVM98 to run
Posted by Weldon Washburn <we...@gmail.com>.
On 5/1/06, Archie Cobbs <ar...@dellroad.org> wrote:
> Weldon Washburn wrote:
> >> If the ACC_INTERFACE flag of this class file is set, its ACC_ABSTRACT
> >> flag must also be set (§2.13.1) and its ACC_PUBLIC flag may be set.
> >> Such a class file may not have any of the other flags in Table 4.1 set.
> >>
> >> It's interesting to hear that Sun (I assume?) doesn't follow this.
> >
> > Are you able to confirm the behavior I am seeing on your system? I
> > ask because I would hate to find out the problem is caused by some
> > glitch in my environment. You should be able to test for the problem
> > with specJVM98 _209_db. Because of spec licensing rules, I may not be
> > able to give you my hacked up source to try.
>
> What's in the classfile? You can use "cfdump" to check, if you've got
> that built. The 0x0400 bit of access_flags should be set for ABSTRACT.
>
Good idea to use cfdump. I now suspect it was a glitch in my
environment. It might have been a wild pointer somewhere. I can no
longer reproduce the problem.
> >> JCHEVM does agressive linking. This behavior is inherited from JCVM
> >> which was optimized for pre-compiled objects. Agressive linking is
> >> within the JVM spec, which allows flexibility in this area. The problem
> >> you see is one downside of the approach.
> >
> > hmmm.... is there any facility to turn off JCHEVM's agressive linking?
> > That is, let the linking happen only at first use of the class. If
> > not, the choices are to:
> > a)
> > implement AWT and any other missing libs (this may be lots of work)
> > b)
> > comment out unused but offending classes that are in specJVM98 (ugly!)
> > c)
> > use some other benchmarks to demo Harmony LUNI on gnuclasspathadapter
> > (and have to respond to questions why specJVM98 does not work)
>
> JCHEVM resolves all of the symbolic references in a class at once,
> but not until it has to. So the linking does only happen at "first use"
> of the class, but at that time the entire class' references are resolved
> rather than just whatever method you happen to touch first.
> There's no way to fix this easily unfortunately.
>
> In any case it seems like trying to get specJVM to work seems pretty
> ambitious at this point, given that you just got System.out.println()
> working... there are probably more urgent things to fix than AWT, no?
Agreed. Fixing AWT so that is runs with gnuclasspathadapter/JCHEVM is
the hard way to bring up the system.
> E.g., you could try the Mauve test suite.
Good idea. I will try to look at mauve soon. I don't know anything
about it. Do you know if there there any Apache license compatibility
issues?
>
> Looking forward to getting this stuff committed at some point... !
Thanks. I agree with you. Hacking on a private copy of Harmony
Classlibs is growing stale. It would be much more efficient to commit
the mods to Apache svn server.
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] gnuclasspathadapter -- current status on getting specJVM98
to run
Posted by Archie Cobbs <ar...@dellroad.org>.
Weldon Washburn wrote:
>> If the ACC_INTERFACE flag of this class file is set, its ACC_ABSTRACT
>> flag must also be set (§2.13.1) and its ACC_PUBLIC flag may be set.
>> Such a class file may not have any of the other flags in Table 4.1 set.
>>
>> It's interesting to hear that Sun (I assume?) doesn't follow this.
>
> Are you able to confirm the behavior I am seeing on your system? I
> ask because I would hate to find out the problem is caused by some
> glitch in my environment. You should be able to test for the problem
> with specJVM98 _209_db. Because of spec licensing rules, I may not be
> able to give you my hacked up source to try.
What's in the classfile? You can use "cfdump" to check, if you've got
that built. The 0x0400 bit of access_flags should be set for ABSTRACT.
>> JCHEVM does agressive linking. This behavior is inherited from JCVM
>> which was optimized for pre-compiled objects. Agressive linking is
>> within the JVM spec, which allows flexibility in this area. The problem
>> you see is one downside of the approach.
>
> hmmm.... is there any facility to turn off JCHEVM's agressive linking?
> That is, let the linking happen only at first use of the class. If
> not, the choices are to:
> a)
> implement AWT and any other missing libs (this may be lots of work)
> b)
> comment out unused but offending classes that are in specJVM98 (ugly!)
> c)
> use some other benchmarks to demo Harmony LUNI on gnuclasspathadapter
> (and have to respond to questions why specJVM98 does not work)
JCHEVM resolves all of the symbolic references in a class at once,
but not until it has to. So the linking does only happen at "first use"
of the class, but at that time the entire class' references are resolved
rather than just whatever method you happen to touch first.
There's no way to fix this easily unfortunately.
In any case it seems like trying to get specJVM to work seems pretty
ambitious at this point, given that you just got System.out.println()
working... there are probably more urgent things to fix than AWT, no?
E.g., you could try the Mauve test suite.
Looking forward to getting this stuff committed at some point... !
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] gnuclasspathadapter -- current status on getting specJVM98 to run
Posted by Weldon Washburn <we...@gmail.com>.
On 5/1/06, Archie Cobbs <ar...@dellroad.org> wrote:
> Weldon Washburn wrote:
> > There was an unexpected and surprising parsing problem when running
> > _209_db on JCHEVM. The procedure called, _jc_parse_classfile(), does
> > some basic verification of a class file. In specific, it verifies
> > that a class with the ACC_INTERFACE attribute set also has the
> > ACC_ABSTRACT bit set. It turns out that _209_db has an interface
> > without the abstract bit set. _209_db will run without warning or
> > error on a product JVM but throws a "ClassFormatError" on JCHEVM. The
> > temporary patch is to comment out JCHEVM code that throws the
> > ClassFormatError. This problem needs further investigation.
>
> JVM specification, section 4.1:
> http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#74353
>
> If the ACC_INTERFACE flag of this class file is set, its ACC_ABSTRACT
> flag must also be set (§2.13.1) and its ACC_PUBLIC flag may be set.
> Such a class file may not have any of the other flags in Table 4.1 set.
>
> It's interesting to hear that Sun (I assume?) doesn't follow this.
Archie,
Are you able to confirm the behavior I am seeing on your system? I
ask because I would hate to find out the problem is caused by some
glitch in my environment. You should be able to test for the problem
with specJVM98 _209_db. Because of spec licensing rules, I may not be
able to give you my hacked up source to try.
>
> > Another problem is that JCHEVM seems to throw a fatal exception during
> > load time if the code being loaded refers to a class that is nowhere
> > to be found. I think the JVM Spec says this exception should be
> > delayed until execution time. The specific problem is that _209_db
> > code refers to AWT classes. Even though _209_db is run with the
> > console configuration, when the classes load they cause JCHEVM to
> > attempt to load AWT classes that can't be found. The workaround is
> > really ugly -- comment out the AWT code in the spec benchmarks.
>
> JCHEVM does agressive linking. This behavior is inherited from JCVM
> which was optimized for pre-compiled objects. Agressive linking is
> within the JVM spec, which allows flexibility in this area. The problem
> you see is one downside of the approach.
hmmm.... is there any facility to turn off JCHEVM's agressive linking?
That is, let the linking happen only at first use of the class. If
not, the choices are to:
a)
implement AWT and any other missing libs (this may be lots of work)
b)
comment out unused but offending classes that are in specJVM98 (ugly!)
c)
use some other benchmarks to demo Harmony LUNI on gnuclasspathadapter
(and have to respond to questions why specJVM98 does not work)
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] gnuclasspathadapter -- current status on getting specJVM98
to run
Posted by Archie Cobbs <ar...@dellroad.org>.
Weldon Washburn wrote:
> There was an unexpected and surprising parsing problem when running
> _209_db on JCHEVM. The procedure called, _jc_parse_classfile(), does
> some basic verification of a class file. In specific, it verifies
> that a class with the ACC_INTERFACE attribute set also has the
> ACC_ABSTRACT bit set. It turns out that _209_db has an interface
> without the abstract bit set. _209_db will run without warning or
> error on a product JVM but throws a "ClassFormatError" on JCHEVM. The
> temporary patch is to comment out JCHEVM code that throws the
> ClassFormatError. This problem needs further investigation.
JVM specification, section 4.1:
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#74353
If the ACC_INTERFACE flag of this class file is set, its ACC_ABSTRACT
flag must also be set (§2.13.1) and its ACC_PUBLIC flag may be set.
Such a class file may not have any of the other flags in Table 4.1 set.
It's interesting to hear that Sun (I assume?) doesn't follow this.
> Another problem is that JCHEVM seems to throw a fatal exception during
> load time if the code being loaded refers to a class that is nowhere
> to be found. I think the JVM Spec says this exception should be
> delayed until execution time. The specific problem is that _209_db
> code refers to AWT classes. Even though _209_db is run with the
> console configuration, when the classes load they cause JCHEVM to
> attempt to load AWT classes that can't be found. The workaround is
> really ugly -- comment out the AWT code in the spec benchmarks.
JCHEVM does agressive linking. This behavior is inherited from JCVM
which was optimized for pre-compiled objects. Agressive linking is
within the JVM spec, which allows flexibility in this area. The problem
you see is one downside of the approach.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org