public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Trouble building gcj 4.8.1
@ 2013-06-24 13:21 Mike Hearn
  2013-06-24 16:48 ` Mike Hearn
  0 siblings, 1 reply; 21+ messages in thread
From: Mike Hearn @ 2013-06-24 13:21 UTC (permalink / raw)
  To: GCC Java

Hi there,

I am trying to compile GCJ 4.8.1 with --enable-java-maintainer-mode
(as classpath has holes in it I need to fix for my codebase to
compile).

Unfortunately this does not work and I'm unsure why. I have ecj.jar in
the source tree.

~/gcc-build$ ../gcc-4.8.1/configure
--prefix=/usr/local/google/home/hearn/gcc-install
--enable-languages=java --disable-bootstrap
--enable-java-maintainer-mode

... results in the classpath configure script failing:

configure:24065: /usr/local/google/home/hearn/gcc-build/./gcc/gcj
-B/usr/local/google/home/hearn/gcc-build/x86_64-unknown-linux-gnu/32/libjava/
-B/usr/local/google/home/hearn/gcc-build/x86_64-unknown-linux-gnu/32/libjava/
-B/usr/local/google/home/hearn/gcc-build/./gcc/
-B/usr/local/google/home/hearn/gcc-install/x86_64-unknown-linux-gnu/bin/
-B/usr/local/google/home/hearn/gcc-install/x86_64-unknown-linux-gnu/lib/
-isystem /usr/local/google/home/hearn/gcc-install/x86_64-unknown-linux-gnu/include
-isystem /usr/local/google/home/hearn/gcc-install/x86_64-unknown-linux-gnu/sys-include
 -m32 -C -g  -fsource=1.5 -ftarget=1.5 Object.java
Unrecognized option :
-fbootclasspath=./:/usr/local/google/home/hearn/gcc-install/share/java/libgcj-4.8.1.jar

Why would GCJ be unable to recognize the -fbootclasspath option?  This
seems an obscure failure.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-24 13:21 Trouble building gcj 4.8.1 Mike Hearn
@ 2013-06-24 16:48 ` Mike Hearn
  2013-06-24 17:04   ` Andrew Haley
  0 siblings, 1 reply; 21+ messages in thread
From: Mike Hearn @ 2013-06-24 16:48 UTC (permalink / raw)
  To: GCC Java

Another problem I noticed is that the class files in the source tree
don't seem to match the java files. When was the last time someone
actually ran --enable-java-maintainer-mode and checked in the results?
For instance the class file for java.lang.String is lacking the
Charset accepting c'tors, but the Java file has them??

On Mon, Jun 24, 2013 at 3:21 PM, Mike Hearn <mike@plan99.net> wrote:
> Hi there,
>
> I am trying to compile GCJ 4.8.1 with --enable-java-maintainer-mode
> (as classpath has holes in it I need to fix for my codebase to
> compile).
>
> Unfortunately this does not work and I'm unsure why. I have ecj.jar in
> the source tree.
>
> ~/gcc-build$ ../gcc-4.8.1/configure
> --prefix=/usr/local/google/home/hearn/gcc-install
> --enable-languages=java --disable-bootstrap
> --enable-java-maintainer-mode
>
> ... results in the classpath configure script failing:
>
> configure:24065: /usr/local/google/home/hearn/gcc-build/./gcc/gcj
> -B/usr/local/google/home/hearn/gcc-build/x86_64-unknown-linux-gnu/32/libjava/
> -B/usr/local/google/home/hearn/gcc-build/x86_64-unknown-linux-gnu/32/libjava/
> -B/usr/local/google/home/hearn/gcc-build/./gcc/
> -B/usr/local/google/home/hearn/gcc-install/x86_64-unknown-linux-gnu/bin/
> -B/usr/local/google/home/hearn/gcc-install/x86_64-unknown-linux-gnu/lib/
> -isystem /usr/local/google/home/hearn/gcc-install/x86_64-unknown-linux-gnu/include
> -isystem /usr/local/google/home/hearn/gcc-install/x86_64-unknown-linux-gnu/sys-include
>  -m32 -C -g  -fsource=1.5 -ftarget=1.5 Object.java
> Unrecognized option :
> -fbootclasspath=./:/usr/local/google/home/hearn/gcc-install/share/java/libgcj-4.8.1.jar
>
> Why would GCJ be unable to recognize the -fbootclasspath option?  This
> seems an obscure failure.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-24 16:48 ` Mike Hearn
@ 2013-06-24 17:04   ` Andrew Haley
  2013-06-24 17:17     ` Mike Hearn
  0 siblings, 1 reply; 21+ messages in thread
From: Andrew Haley @ 2013-06-24 17:04 UTC (permalink / raw)
  To: Mike Hearn; +Cc: GCC Java

On 06/24/2013 05:48 PM, Mike Hearn wrote:
> Another problem I noticed is that the class files in the source tree
> don't seem to match the java files. When was the last time someone
> actually ran --enable-java-maintainer-mode and checked in the results?
> For instance the class file for java.lang.String is lacking the
> Charset accepting c'tors, but the Java file has them??

It should have happened the last time there was a Classpath import.
You should be able to see this in the revision history.

Patches to synchronize with Classpath are pre-approved.

Andrew.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-24 17:04   ` Andrew Haley
@ 2013-06-24 17:17     ` Mike Hearn
  2013-06-24 17:26       ` Andrew Haley
  0 siblings, 1 reply; 21+ messages in thread
From: Mike Hearn @ 2013-06-24 17:17 UTC (permalink / raw)
  To: Andrew Haley; +Cc: GCC Java

> It should have happened the last time there was a Classpath import.
> You should be able to see this in the revision history.

Seems like it didn't always happen - compare:

http://gcc.gnu.org/viewcvs/gcc/trunk/libjava/classpath/java/lang/?dir_pagestart=75
http://gcc.gnu.org/viewcvs/gcc/trunk/libjava/classpath/lib/java/lang/String.class?view=log

The last time String.java was touched was 6 months ago, but the class
file was last updated 15 months ago.

If I could make --enable-java-maintainer-mode work then it wouldn't
matter, but maybe re-genning the class files and checking them in
would be a good idea, seeing as they're provided.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-24 17:17     ` Mike Hearn
@ 2013-06-24 17:26       ` Andrew Haley
  2013-06-24 20:36         ` Matthias Klose
  2013-06-25 13:39         ` Mike Hearn
  0 siblings, 2 replies; 21+ messages in thread
From: Andrew Haley @ 2013-06-24 17:26 UTC (permalink / raw)
  To: Mike Hearn; +Cc: GCC Java

On 06/24/2013 06:17 PM, Mike Hearn wrote:
>> It should have happened the last time there was a Classpath import.
>> You should be able to see this in the revision history.
> 
> Seems like it didn't always happen - compare:
> 
> http://gcc.gnu.org/viewcvs/gcc/trunk/libjava/classpath/java/lang/?dir_pagestart=75
> http://gcc.gnu.org/viewcvs/gcc/trunk/libjava/classpath/lib/java/lang/String.class?view=log
> 
> The last time String.java was touched was 6 months ago, but the class
> file was last updated 15 months ago.
> 
> If I could make --enable-java-maintainer-mode work then it wouldn't
> matter, but maybe re-genning the class files and checking them in
> would be a good idea, seeing as they're provided.

OK, so let's try to find out why it doesn't work.  You must have an
executable called ecj1 in your path for use by the build.  My ecj1 is:

#!/bin/sh
unset LD_LIBRARY_PATH
gij -cp /home/aph/gcc/trunk/ecj.jar \
    org.eclipse.jdt.internal.compiler.batch.GCCMain \
    ${1+"$@"}

Andrew.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-24 17:26       ` Andrew Haley
@ 2013-06-24 20:36         ` Matthias Klose
  2013-06-25 13:39         ` Mike Hearn
  1 sibling, 0 replies; 21+ messages in thread
From: Matthias Klose @ 2013-06-24 20:36 UTC (permalink / raw)
  To: Andrew Haley; +Cc: Mike Hearn, GCC Java

Am 24.06.2013 19:26, schrieb Andrew Haley:
> On 06/24/2013 06:17 PM, Mike Hearn wrote:
>>> It should have happened the last time there was a Classpath import.
>>> You should be able to see this in the revision history.
>>
>> Seems like it didn't always happen - compare:
>>
>> http://gcc.gnu.org/viewcvs/gcc/trunk/libjava/classpath/java/lang/?dir_pagestart=75
>> http://gcc.gnu.org/viewcvs/gcc/trunk/libjava/classpath/lib/java/lang/String.class?view=log
>>
>> The last time String.java was touched was 6 months ago, but the class
>> file was last updated 15 months ago.
>>
>> If I could make --enable-java-maintainer-mode work then it wouldn't
>> matter, but maybe re-genning the class files and checking them in
>> would be a good idea, seeing as they're provided.
> 
> OK, so let's try to find out why it doesn't work.  You must have an
> executable called ecj1 in your path for use by the build.  My ecj1 is:
> 
> #!/bin/sh
> unset LD_LIBRARY_PATH
> gij -cp /home/aph/gcc/trunk/ecj.jar \
>     org.eclipse.jdt.internal.compiler.batch.GCCMain \
>     ${1+"$@"}

and make sure to use the ecj.jar provided on gcc.gnu.org.

  Matthias

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-24 17:26       ` Andrew Haley
  2013-06-24 20:36         ` Matthias Klose
@ 2013-06-25 13:39         ` Mike Hearn
  2013-06-25 13:53           ` Mike Hearn
                             ` (2 more replies)
  1 sibling, 3 replies; 21+ messages in thread
From: Mike Hearn @ 2013-06-25 13:39 UTC (permalink / raw)
  To: Andrew Haley; +Cc: GCC Java

Hmm, it seems there's one on my system already and it looks like the
script at the bottom of this mail. I guess it's from Debian and isn't
correct in some way. There's also an ecj1 that was installed when I
ran without --enable-java-maintainer-mode but it's in
$PREFIX/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/ecj1 - it seems
like running them gives the same outputs. Perhaps ecj1 was meant to be
installed as a symlink to the binary in libexec?

I put Andrew's script in my PATH and tried again, eventually got it
working. Unfortunately now I have another problem - it seems that
String.java is special, and that's the one I want to be recompiled. If
I introduce a syntax error into some  other class like
java.util.ArrayList and do a "rm compile-classes; make" in the libjava
build dir, it does indeed fail. Although it's impossible to see the
error as there are ~100,000+ warnings and I'm not sure yet how to
disable them :-) But, if I introduce a syntax error into String.java
and do the same thing, the compilation works fine.

I am not entirely surprised by the special-ness of String.java given
the comment at the top which says

  // WARNING: String is a CORE class in the bootstrap cycle. See the comments
  // in vm/reference/java/lang/Runtime for implications of this fact.

but the named file does not exist and the closest one that does
(VMRuntime.java) doesn't talk about bootstrap cycles at all.

Any idea why it's not building? Perhaps this is why the class file
didn't get refreshed last time ....



#! /bin/sh

case "$*" in
  *-bootclasspath*) ;;
  *)
    if [ ! -f /usr/lib/jvm/java-gcj/jre/lib/rt.jar ]; then
      bcoption="-bootclasspath /usr/share/java/libgcj-4.6.jar"
    fi
esac

if [ -x /usr/bin/ecj-gcj ]; then

    exec /usr/bin/ecj-gcj \
$bcoption ${1+"$@"}

else

    case $CLASSPATH in
      */usr/share/java/ecj.jar*) ;;
      */usr/share/java/eclipse-ecj.jar*) ;;
      *) CLASSPATH=${CLASSPATH:+$CLASSPATH:}/usr/share/java/eclipse-ecj.jar
    esac
    export CLASSPATH

    exec /usr/bin/gij-4.6 \
        -Dgnu.gcj.precompiled.db.path=/var/lib/gcj-$ver/classmap.db \
        -Djava.ext.dirs=/usr/lib/java-ext:/usr/share/java-ext \
        org.eclipse.jdt.internal.compiler.batch.Main $bcoption ${1+"$@"}

fi

On Mon, Jun 24, 2013 at 7:26 PM, Andrew Haley <aph@redhat.com> wrote:
> On 06/24/2013 06:17 PM, Mike Hearn wrote:
>>> It should have happened the last time there was a Classpath import.
>>> You should be able to see this in the revision history.
>>
>> Seems like it didn't always happen - compare:
>>
>> http://gcc.gnu.org/viewcvs/gcc/trunk/libjava/classpath/java/lang/?dir_pagestart=75
>> http://gcc.gnu.org/viewcvs/gcc/trunk/libjava/classpath/lib/java/lang/String.class?view=log
>>
>> The last time String.java was touched was 6 months ago, but the class
>> file was last updated 15 months ago.
>>
>> If I could make --enable-java-maintainer-mode work then it wouldn't
>> matter, but maybe re-genning the class files and checking them in
>> would be a good idea, seeing as they're provided.
>
> OK, so let's try to find out why it doesn't work.  You must have an
> executable called ecj1 in your path for use by the build.  My ecj1 is:
>
> #!/bin/sh
> unset LD_LIBRARY_PATH
> gij -cp /home/aph/gcc/trunk/ecj.jar \
>     org.eclipse.jdt.internal.compiler.batch.GCCMain \
>     ${1+"$@"}
>
> Andrew.
>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-25 13:39         ` Mike Hearn
@ 2013-06-25 13:53           ` Mike Hearn
  2013-06-25 14:07             ` Andrew Haley
  2013-06-25 14:05           ` Andrew Haley
  2013-06-25 14:05           ` Andrew Haley
  2 siblings, 1 reply; 21+ messages in thread
From: Mike Hearn @ 2013-06-25 13:53 UTC (permalink / raw)
  To: Andrew Haley; +Cc: GCC Java

> Any idea why it's not building? Perhaps this is why the class file
> didn't get refreshed last time ....

Ah, it seems libjava/java/lang/String.java takes precedence over
libjava/classpath/java/lang/String.java

Looks like the libjava version is several years old. I tried a simple
replacement and it didn't build, probably because String depends on
various runtime internal things.

I feel like I am reaching the limits of what I can figure out by
myself. I'm trying to get the c'tors that include Charset so I might
try a surgical patch to the libjava/java/lang version, but there's
obviously several years of fixes and optimizations to the Classpath
version which would be nice to have. And I see that there are older
versions of other java.lang files in there too.

What's involved in syncing those core classes up to the latest
classpath versions?

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-25 13:39         ` Mike Hearn
  2013-06-25 13:53           ` Mike Hearn
@ 2013-06-25 14:05           ` Andrew Haley
  2013-06-25 14:05           ` Andrew Haley
  2 siblings, 0 replies; 21+ messages in thread
From: Andrew Haley @ 2013-06-25 14:05 UTC (permalink / raw)
  To: Mike Hearn; +Cc: GCC Java

On 06/25/2013 02:39 PM, Mike Hearn wrote:
> But, if I introduce a syntax error into String.java
> and do the same thing, the compilation works fine.

Are you sure you're editing the right one?  It's in
gcc/trunk/libjava/java/lang/String.java

Andrew.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-25 13:39         ` Mike Hearn
  2013-06-25 13:53           ` Mike Hearn
  2013-06-25 14:05           ` Andrew Haley
@ 2013-06-25 14:05           ` Andrew Haley
  2013-06-25 14:10             ` Mike Hearn
  2 siblings, 1 reply; 21+ messages in thread
From: Andrew Haley @ 2013-06-25 14:05 UTC (permalink / raw)
  To: Mike Hearn; +Cc: GCC Java

On 06/25/2013 02:39 PM, Mike Hearn wrote:
> Hmm, it seems there's one on my system already and it looks like the
> script at the bottom of this mail. I guess it's from Debian and isn't
> correct in some way. There's also an ecj1 that was installed when I
> ran without --enable-java-maintainer-mode but it's in
> $PREFIX/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/ecj1 - it seems
> like running them gives the same outputs. Perhaps ecj1 was meant to be
> installed as a symlink to the binary in libexec?

No, you have to put it in your own path.  It does say so in the
instructions.

Andrew.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-25 13:53           ` Mike Hearn
@ 2013-06-25 14:07             ` Andrew Haley
  0 siblings, 0 replies; 21+ messages in thread
From: Andrew Haley @ 2013-06-25 14:07 UTC (permalink / raw)
  To: Mike Hearn; +Cc: GCC Java

On 06/25/2013 02:53 PM, Mike Hearn wrote:
>> Any idea why it's not building? Perhaps this is why the class file
>> didn't get refreshed last time ....
> 
> Ah, it seems libjava/java/lang/String.java takes precedence over
> libjava/classpath/java/lang/String.java
> 
> Looks like the libjava version is several years old. I tried a simple
> replacement and it didn't build, probably because String depends on
> various runtime internal things.

Indeed.

> I feel like I am reaching the limits of what I can figure out by
> myself. I'm trying to get the c'tors that include Charset so I might
> try a surgical patch to the libjava/java/lang version, but there's
> obviously several years of fixes and optimizations to the Classpath
> version which would be nice to have. And I see that there are older
> versions of other java.lang files in there too.
> 
> What's involved in syncing those core classes up to the latest
> classpath versions?

It's ninja stuff, really.  What is your goal in all of this?

Andrew.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-25 14:05           ` Andrew Haley
@ 2013-06-25 14:10             ` Mike Hearn
  2013-06-25 14:12               ` Andrew Haley
  0 siblings, 1 reply; 21+ messages in thread
From: Mike Hearn @ 2013-06-25 14:10 UTC (permalink / raw)
  To: Andrew Haley; +Cc: GCC Java

> No, you have to put it in your own path.  It does say so in the
> instructions.

Ah. The docs say:

"If this option is given, the ‘libjava’ build will create and install
an ecj1 executable which uses this jar file at runtime.  If this
option is not given, but an ecj.jar file is found in the topmost
source tree at configure time, then the ‘libgcj’ build will create and
install ecj1, and will also install the discovered ecj.jar into a
suitable place in the install tree."

I interpreted "create and install" to mean it'll be put into bin by
"make install", it might be clearer if it said explicitly that you
have to copy it or put the script there yourself.


My goal with all this is to compile and run a Java program as a MIPS
program that is as small as possible, which I intend to do by:

 - Compiling with GCJ, as MIPS supporting Java VMs are rare
 - Enabling as many dead code elimination passes as possible,
including LTO with a static libgcj

in the hope that I can get a nice small, self contained binary out of the end.

As a bonus, I'd also like to enable usage of a library that this
program uses from C++ codebases using CNI, although that's secondary
right now.

Could you maybe elaborate on the ninja stuff? Why are there two copies
of these core classes? How much effort is it to fix things up - are we
talking a few days here, a few weeks, a few months?

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-25 14:10             ` Mike Hearn
@ 2013-06-25 14:12               ` Andrew Haley
  2013-06-25 14:15                 ` Mike Hearn
  0 siblings, 1 reply; 21+ messages in thread
From: Andrew Haley @ 2013-06-25 14:12 UTC (permalink / raw)
  To: Mike Hearn; +Cc: GCC Java

On 06/25/2013 03:10 PM, Mike Hearn wrote:
>> No, you have to put it in your own path.  It does say so in the
>> instructions.
> 
> Ah. The docs say:
> 
> "If this option is given, the ‘libjava’ build will create and install
> an ecj1 executable which uses this jar file at runtime.  If this
> option is not given, but an ecj.jar file is found in the topmost
> source tree at configure time, then the ‘libgcj’ build will create and
> install ecj1, and will also install the discovered ecj.jar into a
> suitable place in the install tree."
> 
> I interpreted "create and install" to mean it'll be put into bin by
> "make install", it might be clearer if it said explicitly that you
> have to copy it or put the script there yourself.
> 
> 
> My goal with all this is to compile and run a Java program as a MIPS
> program that is as small as possible, which I intend to do by:
> 
>  - Compiling with GCJ, as MIPS supporting Java VMs are rare
>  - Enabling as many dead code elimination passes as possible,
> including LTO with a static libgcj
> 
> in the hope that I can get a nice small, self contained binary out of the end.

OK.
> As a bonus, I'd also like to enable usage of a library that this
> program uses from C++ codebases using CNI, although that's secondary
> right now.
> 
> Could you maybe elaborate on the ninja stuff? Why are there two copies
> of these core classes? How much effort is it to fix things up - are we
> talking a few days here, a few weeks, a few months?

I'm trying to find out what you want to do to java.lang.String.  Tell me
that, and we'll take it from there.

Andrew.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-25 14:12               ` Andrew Haley
@ 2013-06-25 14:15                 ` Mike Hearn
  2013-06-25 14:21                   ` Andrew Haley
  0 siblings, 1 reply; 21+ messages in thread
From: Mike Hearn @ 2013-06-25 14:15 UTC (permalink / raw)
  To: Andrew Haley; +Cc: GCC Java

> I'm trying to find out what you want to do to java.lang.String.  Tell me
> that, and we'll take it from there.

At the moment, supporting the methods that take java.nio.Charset. I'm
going to try and just hack it up with something like this:

  public String(byte[] data, int offset, int count, Charset encoding)
    throws UnsupportedEncodingException
  {
    init (data, offset, count, encoding.name());
  }

and then the same for getBytes().

But in general I anticipate that I'll continue to hit stubs or quirks
in classpath so I'm trying to figure out how best to reach my goal,
which will likely involve fixing up various things along the way. For
instance, my first yak-shaving goal is to run the test suite for the
core library of this app and then hack/fix until all the tests pass.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-25 14:15                 ` Mike Hearn
@ 2013-06-25 14:21                   ` Andrew Haley
  2013-06-28  1:28                     ` Andïï
  2013-07-02 14:53                     ` Bryce McKinlay
  0 siblings, 2 replies; 21+ messages in thread
From: Andrew Haley @ 2013-06-25 14:21 UTC (permalink / raw)
  To: Mike Hearn; +Cc: GCC Java

On 06/25/2013 03:15 PM, Mike Hearn wrote:
>> I'm trying to find out what you want to do to java.lang.String.  Tell me
>> that, and we'll take it from there.
> 
> At the moment, supporting the methods that take java.nio.Charset. I'm
> going to try and just hack it up with something like this:
> 
>   public String(byte[] data, int offset, int count, Charset encoding)
>     throws UnsupportedEncodingException
>   {
>     init (data, offset, count, encoding.name());
>   }
> 
> and then the same for getBytes().

OK.  I think you can just add those methods.

> But in general I anticipate that I'll continue to hit stubs or quirks
> in classpath so I'm trying to figure out how best to reach my goal,
> which will likely involve fixing up various things along the way. For
> instance, my first yak-shaving goal is to run the test suite for the
> core library of this app and then hack/fix until all the tests pass.

In general, we follow Classpath except for a few core classes -- and
String is one of those.  Major hacking on core classes requires compiler
changes, so I strongly recommend you don't do that.  For example, better
not add any fields.  But in general for almost the whole class library
you won't have so much trouble.

Andrew.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-25 14:21                   ` Andrew Haley
@ 2013-06-28  1:28                     ` Andïï
  2013-06-28  9:06                       ` Andrew Haley
  2013-07-02 14:53                     ` Bryce McKinlay
  1 sibling, 1 reply; 21+ messages in thread
From: Andïï @ 2013-06-28  1:28 UTC (permalink / raw)
  To: Andrew Haley; +Cc: Mike Hearn, GCC Java

On 25 June 2013 09:21, Andrew Haley <aph@redhat.com> wrote:
> On 06/25/2013 03:15 PM, Mike Hearn wrote:
>>> I'm trying to find out what you want to do to java.lang.String.  Tell me
>>> that, and we'll take it from there.
>>
>> At the moment, supporting the methods that take java.nio.Charset. I'm
>> going to try and just hack it up with something like this:
>>
>>   public String(byte[] data, int offset, int count, Charset encoding)
>>     throws UnsupportedEncodingException
>>   {
>>     init (data, offset, count, encoding.name());
>>   }
>>
>> and then the same for getBytes().
>
> OK.  I think you can just add those methods.
>
>> But in general I anticipate that I'll continue to hit stubs or quirks
>> in classpath so I'm trying to figure out how best to reach my goal,
>> which will likely involve fixing up various things along the way. For
>> instance, my first yak-shaving goal is to run the test suite for the
>> core library of this app and then hack/fix until all the tests pass.
>
> In general, we follow Classpath except for a few core classes -- and
> String is one of those.  Major hacking on core classes requires compiler
> changes, so I strongly recommend you don't do that.  For example, better
> not add any fields.  But in general for almost the whole class library
> you won't have so much trouble.
>
> Andrew.
>
>

From what I recall, I tried to update gcj's copy of java.lang.String a
few years ago -
I have a feeling it may have even been for these methods - and wasn't
very successful.
I think the result is still tucked away in gcc's Bugzilla.  The
structure is quite different
from Classpath's and specific to how gcj works internally, as String
has to work at both
the Java and native level.

Silly question, but if Classpath has what you want already, why not
just hook it up with
a VM like CACAO that uses it directly?  It would probably take a
fraction of the time it
takes to even build gcj.  Why do you specifically want gcj?
--
Andii :-)

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-28  1:28                     ` Andïï
@ 2013-06-28  9:06                       ` Andrew Haley
  0 siblings, 0 replies; 21+ messages in thread
From: Andrew Haley @ 2013-06-28  9:06 UTC (permalink / raw)
  To: Andïï; +Cc: Mike Hearn, GCC Java

On 06/28/2013 02:28 AM, Andïï wrote:
> Silly question, but if Classpath has what you want already, why not
> just hook it up with
> a VM like CACAO that uses it directly?  It would probably take a
> fraction of the time it
> takes to even build gcj.  Why do you specifically want gcj?

Mike has already explained that.  If you want to discuss this, please do
it off-list.

Andrew.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-06-25 14:21                   ` Andrew Haley
  2013-06-28  1:28                     ` Andïï
@ 2013-07-02 14:53                     ` Bryce McKinlay
       [not found]                       ` <CANEZrP1tLxpu818cFGdgma+RVL32yRJJUOyb5m8QF=mhTZVueg@mail.gmail.com>
  1 sibling, 1 reply; 21+ messages in thread
From: Bryce McKinlay @ 2013-07-02 14:53 UTC (permalink / raw)
  To: Andrew Haley; +Cc: Mike Hearn, GCC Java

On Tue, Jun 25, 2013 at 3:21 PM, Andrew Haley <aph@redhat.com> wrote:
> On 06/25/2013 03:15 PM, Mike Hearn wrote:
>>> I'm trying to find out what you want to do to java.lang.String.  Tell me
>>> that, and we'll take it from there.
>>
>> At the moment, supporting the methods that take java.nio.Charset. I'm
>> going to try and just hack it up with something like this:
>>
>>   public String(byte[] data, int offset, int count, Charset encoding)
>>     throws UnsupportedEncodingException
>>   {
>>     init (data, offset, count, encoding.name());
>>   }
>>
>> and then the same for getBytes().
>
> OK.  I think you can just add those methods.
>
>> But in general I anticipate that I'll continue to hit stubs or quirks
>> in classpath so I'm trying to figure out how best to reach my goal,
>> which will likely involve fixing up various things along the way. For
>> instance, my first yak-shaving goal is to run the test suite for the
>> core library of this app and then hack/fix until all the tests pass.
>
> In general, we follow Classpath except for a few core classes -- and
> String is one of those.  Major hacking on core classes requires compiler
> changes, so I strongly recommend you don't do that.  For example, better
> not add any fields.  But in general for almost the whole class library
> you won't have so much trouble.

I think it's only java.lang.Object and java.lang.Class that are
"special" - i.e. could conceivably require compiler changes if you
changed the field layout. As far as I can recall, String isn't really
treated specially in any way.

There should be no problem at all adding those methods and I would
encourage you to go ahead and submit a patch.

Bryce

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
       [not found]                       ` <CANEZrP1tLxpu818cFGdgma+RVL32yRJJUOyb5m8QF=mhTZVueg@mail.gmail.com>
@ 2013-07-03 13:43                         ` Mike Hearn
  2013-07-03 13:47                           ` Andrew Haley
  0 siblings, 1 reply; 21+ messages in thread
From: Mike Hearn @ 2013-07-03 13:43 UTC (permalink / raw)
  To: Bryce McKinlay; +Cc: Andrew Haley, GCC Java

Well, the issue is I'm not sure how to implement them correctly. I did
a quick hack which involves using the existing methods that take
charset names and just calling them with Charset.forName() but I
seriously doubt this is really fully compatible or would pass the Java
test suite. Perhaps it doesn't matter all that much, but if String is
not special it'd be nice to move to the classpath version which seems
to be much more thorough.

On Wed, Jul 3, 2013 at 3:43 PM, Mike Hearn <mike@plan99.net> wrote:
> Well, the issue is I'm not sure how to implement them correctly. I did a
> quick hack which involves using the existing methods that take charset names
> and just calling them with Charset.forName() but I seriously doubt this is
> really fully compatible or would pass the Java test suite. Perhaps it
> doesn't matter all that much, but if String is not special it'd be nice to
> move to the classpath version which seems to be much more thorough.
>
>
> On Tue, Jul 2, 2013 at 4:53 PM, Bryce McKinlay <bmckinlay@gmail.com> wrote:
>>
>> On Tue, Jun 25, 2013 at 3:21 PM, Andrew Haley <aph@redhat.com> wrote:
>> > On 06/25/2013 03:15 PM, Mike Hearn wrote:
>> >>> I'm trying to find out what you want to do to java.lang.String.  Tell
>> >>> me
>> >>> that, and we'll take it from there.
>> >>
>> >> At the moment, supporting the methods that take java.nio.Charset. I'm
>> >> going to try and just hack it up with something like this:
>> >>
>> >>   public String(byte[] data, int offset, int count, Charset encoding)
>> >>     throws UnsupportedEncodingException
>> >>   {
>> >>     init (data, offset, count, encoding.name());
>> >>   }
>> >>
>> >> and then the same for getBytes().
>> >
>> > OK.  I think you can just add those methods.
>> >
>> >> But in general I anticipate that I'll continue to hit stubs or quirks
>> >> in classpath so I'm trying to figure out how best to reach my goal,
>> >> which will likely involve fixing up various things along the way. For
>> >> instance, my first yak-shaving goal is to run the test suite for the
>> >> core library of this app and then hack/fix until all the tests pass.
>> >
>> > In general, we follow Classpath except for a few core classes -- and
>> > String is one of those.  Major hacking on core classes requires compiler
>> > changes, so I strongly recommend you don't do that.  For example, better
>> > not add any fields.  But in general for almost the whole class library
>> > you won't have so much trouble.
>>
>> I think it's only java.lang.Object and java.lang.Class that are
>> "special" - i.e. could conceivably require compiler changes if you
>> changed the field layout. As far as I can recall, String isn't really
>> treated specially in any way.
>>
>> There should be no problem at all adding those methods and I would
>> encourage you to go ahead and submit a patch.
>>
>> Bryce
>
>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-07-03 13:43                         ` Mike Hearn
@ 2013-07-03 13:47                           ` Andrew Haley
  2013-07-03 21:31                             ` Bryce McKinlay
  0 siblings, 1 reply; 21+ messages in thread
From: Andrew Haley @ 2013-07-03 13:47 UTC (permalink / raw)
  To: Mike Hearn; +Cc: Bryce McKinlay, GCC Java

On 07/03/2013 02:43 PM, Mike Hearn wrote:
> if String is
> not special it'd be nice to move to the classpath version which seems
> to be much more thorough.

Definitely.  The only problem is that no-one has had the time to ensure that
nothing breaks.

Andrew.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: Trouble building gcj 4.8.1
  2013-07-03 13:47                           ` Andrew Haley
@ 2013-07-03 21:31                             ` Bryce McKinlay
  0 siblings, 0 replies; 21+ messages in thread
From: Bryce McKinlay @ 2013-07-03 21:31 UTC (permalink / raw)
  To: Andrew Haley; +Cc: Mike Hearn, GCC Java

On Wed, Jul 3, 2013 at 2:47 PM, Andrew Haley <aph@redhat.com> wrote:
> On 07/03/2013 02:43 PM, Mike Hearn wrote:
>> if String is
>> not special it'd be nice to move to the classpath version which seems
>> to be much more thorough.
>
> Definitely.  The only problem is that no-one has had the time to ensure that
> nothing breaks.

Well, although it isn't treated specially by the compiler, libgcj's
String is also largely implemented as native CNI code, where as the
GNU Classpath one is pure Java.

Pure Java is better for most VMs, but not so much for GCJ. libgcj's
version probably performs better than the Classpath implementation
would in the GCJ environment.

> I did a
> quick hack which involves using the existing methods that take charset names
> and just calling them with Charset.forName() but I seriously doubt this is
> really fully compatible or would pass the Java test suite.

Yeah, this should more-or-less work, as long as the Charset in
question is supported by libgcj's native encoders. The native encoders
should be a lot faster than the java.nio.charset ones, too. NIO
buffers don't perform well with GCJ due to it's inability to inline
virtual calls.

Bryce

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2013-07-03 21:31 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-24 13:21 Trouble building gcj 4.8.1 Mike Hearn
2013-06-24 16:48 ` Mike Hearn
2013-06-24 17:04   ` Andrew Haley
2013-06-24 17:17     ` Mike Hearn
2013-06-24 17:26       ` Andrew Haley
2013-06-24 20:36         ` Matthias Klose
2013-06-25 13:39         ` Mike Hearn
2013-06-25 13:53           ` Mike Hearn
2013-06-25 14:07             ` Andrew Haley
2013-06-25 14:05           ` Andrew Haley
2013-06-25 14:05           ` Andrew Haley
2013-06-25 14:10             ` Mike Hearn
2013-06-25 14:12               ` Andrew Haley
2013-06-25 14:15                 ` Mike Hearn
2013-06-25 14:21                   ` Andrew Haley
2013-06-28  1:28                     ` Andïï
2013-06-28  9:06                       ` Andrew Haley
2013-07-02 14:53                     ` Bryce McKinlay
     [not found]                       ` <CANEZrP1tLxpu818cFGdgma+RVL32yRJJUOyb5m8QF=mhTZVueg@mail.gmail.com>
2013-07-03 13:43                         ` Mike Hearn
2013-07-03 13:47                           ` Andrew Haley
2013-07-03 21:31                             ` Bryce McKinlay

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).