Eclipse vs gij/libgcj, unit-at-a-time, -O2 and -O
Sat Nov 8 17:46:00 GMT 2003
On Fri, Nov 07, 2003 at 01:38:13PM -0700, Tom Tromey wrote:
> >>>>> "Mark" == Mark Wielaard <email@example.com> writes:
> Mark> - The easy part is to define the following two properties for making it
> Mark> at least startup and detect gcj as standard JRE (for JDT work):
> Mark> java.vm.version=1.3
> Does eclipse check this? That seems sort of bogus.
The JDT in 3.0 checks this to see if it have a "Standard VM".
It looks bogus indeed, they seem to use the information to generate
a URL to the Sun javadoc of some standard library classes. Blech.
I believe the JikesRVM developers actually made their own VMType plugin
for the JDT so they don't have to depend on Eclipse guessing the right
properties. This is probably also a good idea to do for gcj when the JDT
works completely (it is quite capable already under gij now).
> Mark> org.eclipse.core.runtime.ignoreLockFile=true
> Why do we need this? I suspect this should lead to one or more
> libgcj PRs :-)
3.0 Tries to create a java.nio.channels.FileLock while starting up.
Since our version just throws a NotImplemented Error everything dies
if we don't set this property.
I didn't find so many things to file bug reports for.
Don't have the machine handy now, but the only two things missing
were regexp compile on a String and a unsupported format symbol
in java.text. But both were not really fatal, just annoying.
Will file bug reports when I have access to my test machine and
better internet access.
> Mark> I did disable the verifier in verify.cc. I don't know if that is
> Mark> actually still necessary. Tom, is there a bug report for the issue you
> Mark> had last time with Eclipse? If that cannot be easily fixed maybe we
> Mark> should introduce a gij switch for disabling the verifier.
> I believe the verifier in 3.4 should work fine. It still has one bug
> pointed out by the mauve verifier tests, but as I recall this is a
> trivial problem and results in the acceptance of invalid methods (so
> it shouldn't erroneously reject anything).
> Please try it. If you find a problem, let me know. I definitely want
> this working for 3.4.
I did try to enable it, but then it first wouldn't compile with -O.
(You have compile verify.cc explicitly with -O2.)
But then Eclipse wouldn't startup at all (again the first Method.invoke call
that is used in the startup.jar to bootstrap eclipse itself).
Didn't investigate much further. But strangly the compiler doesn't crash on
verify.cc with just -O when you remove the two line implementation of
_Jv_VerifyMethod(). So this file might be a good test case for finding the
bug in the g++ compiler when using -O and not -O2.
More information about the Java