RE: [freenet-tech] Technology / Features

RE: [freenet-tech] Technology / Features

[Boehm, Hans]

David Mosberger has been working on ways to support dynamically generated
(e.g. by a JIT) code in the IA64 unwind interface.

I would guess that interpreter frames can also be handled by noticing that
the PC in a certain frame points to the interpreter, and then looking at
alternate data structures.  But I doubt this has been though through.

Hans

> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Thursday, February 28, 2002 5:21 PM
> To: Jeff Sturm
> Cc: Bryce McKinlay; java@gcc.gnu.org
> Subject: Re: [freenet-tech] Technology / Features
> 
> 
> >>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:
> 
> Jeff> Well, since libunwind has this working (on ia64, at the moment)
> Jeff> it would make sense to look at their API, with or without using
> Jeff> any of their code.  The intent of the author, David Mosberger,
> Jeff> seems to be making this a drop-in replacement and perhaps offer
> Jeff> it to gcc and/or glibc.
> 
> We're going to need something special eventually, because we need to
> know the class corresponding to every stack frame -- including
> interpreter and/or JIT frames.
> 
> I don't have a timeframe for this stuff, of course, but one of my big
> goals is to eventually get libgcj used as the Java implementation in
> Mozilla.  This means we'll need AWT, plus all the security stuff we've
> avoided for so long (stack overflow checking, SecurityManager and thus
> stack trace support, plus a complete SecurityManager audit of the
> libraries -- a lot of work).
> 
> Maybe we can get some interpreter/JIT support taken into consideration
> by libunwind.
> 
> Tom
> 

RE: [freenet-tech] Technology / Features

[David Mosberger]

>>>>> On Fri, 1 Mar 2002 15:29:38 -0800 , "Boehm, Hans" <hans_boehm@hp.com> said:

  Hans> David Mosberger has been working on ways to support
  Hans> dynamically generated (e.g. by a JIT) code in the IA64 unwind
  Hans> interface.

It's still a bit early for me to talk about support for dynamically
generated code.  I expect to work on this over the coming weeks and
would definitely appreciate feedback.  Once there is a real proposal,
I'll circulate it among interested folks but if you have suggestions
or concerns in the meantime, just send me mail (or better still, send
it to the mailing list at libunwind@linux.hpl.hp.com).

  Hans> I would guess that interpreter frames can also be handled by
  Hans> noticing that the PC in a certain frame points to the
  Hans> interpreter, and then looking at alternate data structures.
  Hans> But I doubt this has been though through.

I discussed this briefly with Hans and it sounds it might be the case
that the contents of the language-specific data area is under your
(Java) control?  If so, perhaps you can encode the needed info in the
LSDA.  libunwind definitely gives you access to this area.

	--david

Re: [freenet-tech] Technology / Features

[Tom Tromey]

>>>>> "David" == David Mosberger <davidm@napali.hpl.hp.com> writes:

David> I discussed this briefly with Hans and it sounds it might be
David> the case that the contents of the language-specific data area
David> is under your (Java) control?  If so, perhaps you can encode
David> the needed info in the LSDA.  libunwind definitely gives you
David> access to this area.

I don't know what the LSDA is.  Is there some base document I can read
to get up to speed?

Anyway, our interpreter is a pretty standard bytecode interpreter.
The PC ranges reported on the stack will always be in one particular
method.  We'd need to be able to specify the real underlying
class/method name on a per-thread basis.

Tom

Re: [freenet-tech] Technology / Features

[David Mosberger]

>>>>> On 01 Mar 2002 20:45:37 -0700, Tom Tromey <tromey@redhat.com> said:

  Tom> I don't know what the LSDA is.  Is there some base document I
  Tom> can read to get up to speed?

Chapter 11 of the ia64 software conventions and runtime architecture
manual should be a good starting point.  It's ia64-specific, but the
concepts apply to other platforms as well.  The PDF is available at:

  http://developer.intel.com/design/itanium/downloads/24535803s.htm

In particular, Figure 11-2 shows the language specific data area
(LSDA).

  Tom> Anyway, our interpreter is a pretty standard bytecode
  Tom> interpreter.  The PC ranges reported on the stack will always
  Tom> be in one particular method.  We'd need to be able to specify
  Tom> the real underlying class/method name on a per-thread basis.

Hmmh, the LSDA is associated with a particular code range, so it's not
per thread.  I'm not sure the LSDA would buy you much more than a way
to identify a particular frame as being an interpreter frame.  If so,
there are probably easier ways to accomplish this.

	--david

Re: [freenet-tech] Technology / Features

[Tom Tromey]

>>>>> "David" == David Mosberger <davidm@napali.hpl.hp.com> writes:

Tom> Anyway, our interpreter is a pretty standard bytecode
Tom> interpreter.  The PC ranges reported on the stack will always
Tom> be in one particular method.  We'd need to be able to specify
Tom> the real underlying class/method name on a per-thread basis.

David> Hmmh, the LSDA is associated with a particular code range, so
David> it's not per thread.  I'm not sure the LSDA would buy you much
David> more than a way to identify a particular frame as being an
David> interpreter frame.  If so, there are probably easier ways to
David> accomplish this.

I guess what we can do is have our interpreter generate more
information.  We can stack-allocate a frame descriptor that has
information about a given interpreter frame's class and method.  Then
we can link these together and put the information into a per-thread
variable.  Our unwinder can then look in this data structure when it
finds an interpreter frame.

Tom

Re: [freenet-tech] Technology / Features

[Tom Tromey]

>>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

Bryce> http://gcc.gnu.org/ml/java/1999-q3/msg00118.html

Bryce> I think we never integrated it into libgcj mainly because he
Bryce> was a bit dissapointed with its performance when compiled with
Bryce> gcj, but gcj sucked a lot more back then than it does now ;-)

Actually as I recall it was a licensing issue.
Reading his original message, it doesn't seem like there was one.
Maybe something changed; it is hard to remember.

Tom

Re: [freenet-tech] Technology / Features

[Bryce McKinlay]

Mark Wielaard wrote:

>On Fri, 2002-03-01 at 08:30, Bryce McKinlay wrote:
>
>>The cool thing about GCJ is that there arn't any bootstrapping issues 
>>for JITs written in Java. Come to think of it, I wonder why Tom wrote 
>>the verifier in C++ ;-)
>>
>
>OK, I will show my ignorance. Is there actually a real reason that the
>verifier is written in C++. I see the smiley but don't know how to
>interpret it in this situation. Having a verifier written in java would
>be a very nice thing since then we could integrate it with ClassLoader
>so other VMs don't have to implement their own verification.
>

There are a couple of verifiers written in Java that I know about. 
Kresten Krab Thorup (who wrote the libgcj interpreter) wrote one:

http://gcc.gnu.org/ml/java/1999-q3/msg00118.html

I think we never integrated it into libgcj mainly because he was a bit 
dissapointed with its performance when compiled with gcj, but gcj sucked 
a lot more back then than it does now ;-)

There is also another one called JustIce: 
http://bcel.sourceforge.net/(click on JustIce)

regards

Bryce.

Re: [freenet-tech] Technology / Features

[Tom Tromey]

>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:

Mark> OK, I will show my ignorance. Is there actually a real reason
Mark> that the verifier is written in C++. I see the smiley but don't
Mark> know how to interpret it in this situation. Having a verifier
Mark> written in java would be a very nice thing since then we could
Mark> integrate it with ClassLoader so other VMs don't have to
Mark> implement their own verification.

I wrote it in C++ since it made some things easier than C (I can use
objects for type and state information) but it uses less memory and is
more efficient than Java.  That's especially true in the context of
libgcj, where the bytecode and such is available as a `char *' array
and not a jbyte[] -- changing this would have meant reallocating every
method, etc.

Maybe these considerations aren't really important.  There was no way
to know when I started.

Tom

Re: [freenet-tech] Technology / Features

[Mark Wielaard]

Hi,

On Fri, 2002-03-01 at 12:37, Brian Jones wrote:
> 
> At the release of the JikesRVM to the public the IBM folks seemed
> interested in making it work with Classpath in order to make the lives
> of researchers easier.  The current library set comes from some
> company IBM swallowed and isn't all that free.
> 
> There are a few classes that would have to be very different from our
> implementations (not even part of the VM specific set we know and
> love), they asked about including those with Classpath, and I said it
> was okay.  I've never heard anything else from those folks.

John Leuner had a look at it and tried to integrate the JRVM with the
GNU Classpath classes. His latest adventures are here:
http://www-124.ibm.com/pipermail/jikesrvm-researchers/2002-February/000295.html

Cheers,

Mark

Re: [freenet-tech] Technology / Features

[Mark Wielaard]

Hi,

On Fri, 2002-03-01 at 08:30, Bryce McKinlay wrote:
> The cool thing about GCJ is that there arn't any bootstrapping issues 
> for JITs written in Java. Come to think of it, I wonder why Tom wrote 
> the verifier in C++ ;-)

OK, I will show my ignorance. Is there actually a real reason that the
verifier is written in C++. I see the smiley but don't know how to
interpret it in this situation. Having a verifier written in java would
be a very nice thing since then we could integrate it with ClassLoader
so other VMs don't have to implement their own verification.

Cheers,

Mark

Re: [freenet-tech] Technology / Features

[Alexandre Petit-Bianco]

Göran Thyni writes:

> The big one is that it can't inherited from an public inner class.
> I filed a bug report PR-5758.

I have a patch for this one, I checked it in:

  http://gcc.gnu.org/ml/java-patches/2002-q1/msg00585.html

> (should have check the DB more closly PR-5632 seems to be the same issue)

5632 is somewhat related to 5758. The patch fixes both.

./A

Re: [freenet-tech] Technology / Features

[Brian Jones]

Eric Blake <ebb9@email.byu.edu> writes:

> Tom Tromey wrote:
> > 
> > There's also the IBM RJVM (I think that's what it is called), but I
> > haven't really looked at it yet.  It might be doable.
> 
> It's called the JikesRVM (no relation to the jikes compiler except the
> name).  It is a bytecode interpreter implemented completely in Java, at
> least that's what their web site claims.  I haven't looked at it any
> closer myself, either.

At the release of the JikesRVM to the public the IBM folks seemed
interested in making it work with Classpath in order to make the lives
of researchers easier.  The current library set comes from some
company IBM swallowed and isn't all that free.

There are a few classes that would have to be very different from our
implementations (not even part of the VM specific set we know and
love), they asked about including those with Classpath, and I said it
was okay.  I've never heard anything else from those folks.

Brian
-- 
Brian Jones <cbj@gnu.org>

Re: [freenet-tech] Technology / Features

[Andrew Haley]

Jeff Sturm writes:
 > On 28 Feb 2002, Adam Megacz wrote:
 > > Interestingly, why does gcj use DWARF2 info to generate stack traces
 > > on Linux instead of just doing this?
 > 
 > It doesn't.  It uses the backtrace function from glibc.
 > 
 > However backtrace doesn't work on a few targets (alpha) where we can't
 > walk the stack.  For those we could possibly use libunwind, which I
 > haven't closely examined yet.  And libunwind is based on DWARF2.

DWARF2 is certainly the way to do it, and I expect that glibc will
eventually work that way.

Andrew.

Re: [freenet-tech] Technology / Features

[Adam Megacz]

Jeff Sturm <jsturm@one-point.com> writes:
> Alpha uses a register calling convention.

Slick.

  - a

-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com

Re: [freenet-tech] Technology / Features

[Eric Blake]

Tom Tromey wrote:
> 
> There's also the IBM RJVM (I think that's what it is called), but I
> haven't really looked at it yet.  It might be doable.

It's called the JikesRVM (no relation to the jikes compiler except the
name).  It is a bytecode interpreter implemented completely in Java, at
least that's what their web site claims.  I haven't looked at it any
closer myself, either.

-- 
This signature intentionally left boring.

Eric Blake             ebb9@email.byu.edu
  BYU student, free software programmer

Re: [freenet-tech] Technology / Features

[Tom Tromey]

>>>>> "Per" == Per Bothner <per@bothner.com> writes:

Per> No, I think what Tom meant (and said) was using libgcj, including
Per> the bytecode-interpreter (or a JIT, if we add support for that to
Per> gcj).  However, all of the standard classed would be
Per> pre-compiled.

Exactly.

And FWIW, I think ORP integration is a reasonable job.  I've looked at
it a bit and I think it could be done in a week or two.

There's also the IBM RJVM (I think that's what it is called), but I
haven't really looked at it yet.  It might be doable.

Tom

Re: [freenet-tech] Technology / Features

[Jeff Sturm]

On 28 Feb 2002, Adam Megacz wrote:
> Huh. Why can't you walk the stack on Alphas? Don't they push the
> return address when when they execute a CALL?

Alpha uses a register calling convention.  Return address is saved in a
register.  So we know the immediate caller's address, but we don't know
how or where the caller may have saved its return address.

Jeff

Re: [freenet-tech] Technology / Features

[Per Bothner]

Adam Megacz wrote:
> Tom Tromey <tromey@redhat.com> writes:
> 
>>I don't have a timeframe for this stuff, of course, but one of my big
>>goals is to eventually get libgcj used as the Java implementation in
>>Mozilla.
>>
> 
> Woah, cool... so Mozilla would call out to gcj to compile stuff into
> binaries, and then execute the binaries?

No, I think what Tom meant (and said) was using libgcj, including the
bytecode-interpreter (or a JIT, if we add support for that to gcj).
However, all of the standard classed would be pre-compiled.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: [freenet-tech] Technology / Features

[Adam Megacz]

Tom Tromey <tromey@redhat.com> writes:
> I don't have a timeframe for this stuff, of course, but one of my big
> goals is to eventually get libgcj used as the Java implementation in
> Mozilla.

Woah, cool... so Mozilla would call out to gcj to compile stuff into
binaries, and then execute the binaries?

  - a

-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com

Re: [freenet-tech] Technology / Features

[Adam Megacz]

Jeff Sturm <jsturm@one-point.com> writes:
> However backtrace doesn't work on a few targets (alpha) where we can't
> walk the stack.

Huh. Why can't you walk the stack on Alphas? Don't they push the
return address when when they execute a CALL?

  - a

-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com

Re: [freenet-tech] Technology / Features

[Tom Tromey]

>>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:

Jeff> Well, since libunwind has this working (on ia64, at the moment)
Jeff> it would make sense to look at their API, with or without using
Jeff> any of their code.  The intent of the author, David Mosberger,
Jeff> seems to be making this a drop-in replacement and perhaps offer
Jeff> it to gcc and/or glibc.

We're going to need something special eventually, because we need to
know the class corresponding to every stack frame -- including
interpreter and/or JIT frames.

I don't have a timeframe for this stuff, of course, but one of my big
goals is to eventually get libgcj used as the Java implementation in
Mozilla.  This means we'll need AWT, plus all the security stuff we've
avoided for so long (stack overflow checking, SecurityManager and thus
stack trace support, plus a complete SecurityManager audit of the
libraries -- a lot of work).

Maybe we can get some interpreter/JIT support taken into consideration
by libunwind.

Tom

Re: [freenet-tech] Technology / Features

[Jeff Sturm]

On Fri, 1 Mar 2002, Bryce McKinlay wrote:
> RTH said the EH unwinder could easily be modified to fill out a stack 
> trace without actually unwinding,

I agree.

> so this is what we should do for targets using DWARF2 exceptions.

Well, since libunwind has this working (on ia64, at the moment) it would
make sense to look at their API, with or without using any of their code.
The intent of the author, David Mosberger, seems to be making this a
drop-in replacement and perhaps offer it to gcc and/or glibc.

I don't know what rth plans to do.  Here's a link:

http://sources.redhat.com/ml/libc-hacker/2002-01/msg00034.html

Jeff

Re: [freenet-tech] Technology / Features

[Bryce McKinlay]

Jeff Sturm wrote:

>On 28 Feb 2002, Adam Megacz wrote:
>
>>Interestingly, why does gcj use DWARF2 info to generate stack traces
>>on Linux instead of just doing this?
>>

Because it runs on CPUs other than x86, and we don't want to write a 
backtrace function for every single architechture out there ;-)

>It doesn't.  It uses the backtrace function from glibc.
>
>However backtrace doesn't work on a few targets (alpha) where we can't
>walk the stack.  For those we could possibly use libunwind, which I
>haven't closely examined yet.  And libunwind is based on DWARF2.
>

RTH said the EH unwinder could easily be modified to fill out a stack 
trace without actually unwinding, so this is what we should do for 
targets using DWARF2 exceptions.

regards

Bryce.

Re: [freenet-tech] Technology / Features

[Jeff Sturm]

On 28 Feb 2002, Adam Megacz wrote:
> Interestingly, why does gcj use DWARF2 info to generate stack traces
> on Linux instead of just doing this?

It doesn't.  It uses the backtrace function from glibc.

However backtrace doesn't work on a few targets (alpha) where we can't
walk the stack.  For those we could possibly use libunwind, which I
haven't closely examined yet.  And libunwind is based on DWARF2.

Jeff

Re: [freenet-tech] Technology / Features

[Adam Megacz]

Jeff Sturm <jsturm@one-point.com> writes:
> void backtrace(void) {
>   register void *_ebp __asm__("%ebp");
>   unsigned int *rfp;
> 
>   for (rfp = _ebp; rfp; rfp = *(unsigned int **)rfp)
>     printf("%p\n", rfp[1]-5);
> }

Ok, let me revise that from "gcj-mingw will never have stack traces"
to "gcj-mingw will have stack traces very soon" =)

Thanks for the code snippet, I haven't done x86 assembly in eight
years, and I wasn't looking forward to going back to it =)

I'll probably get around to putting this in sometime after 3.1 is
released.

Interestingly, why does gcj use DWARF2 info to generate stack traces
on Linux instead of just doing this?

  - a

-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com

Re: [freenet-tech] Technology / Features

[Andrew Haley]

Adam Megacz writes:
 > 
 > Andrew Haley <aph@cambridge.redhat.com> writes:
 > > Well, I mean it shoudn't be hard to print a list of addresses:
 > 
 > Where will you get that list of addresses from? =)

You walk the stack chain.  Surely it's possible to do that?

Andrew.

Re: [freenet-tech] Technology / Features

[Bryce McKinlay]

Adam Megacz wrote:

>Andrew Haley <aph@cambridge.redhat.com> writes:
>
>>Well, I mean it shoudn't be hard to print a list of addresses:
>>
>
>Where will you get that list of addresses from? =)
>

Doesn't win32 have some equivilent of the glibc backtrace() call? Even 
if it doesn't, unwinding the x86 stack yourself doesn't look hard. All 
you need to grab is the value of the eip for each stack frame.

regards

Bryce.

Re: [freenet-tech] Technology / Features

[Jeff Sturm]

On 27 Feb 2002, Adam Megacz wrote:
> Andrew Haley <aph@cambridge.redhat.com> writes:
> > Well, I mean it shoudn't be hard to print a list of addresses:
> 
> Where will you get that list of addresses from? =)

Why, from the stack frames, of course.

Here's a tiny example for x86:

#include <stdio.h>

void backtrace(void) {
  register void *_ebp __asm__("%ebp");
  unsigned int *rfp;

  for (rfp = _ebp; rfp; rfp = *(unsigned int **)rfp)
    printf("%p\n", rfp[1]-5);
}

void g(void) {
  backtrace();
}

void f(void) {
  g();
}

int main(void) {
  f();
  return 0;
}

Re: [freenet-tech] Technology / Features

[Adam Megacz]

Andrew Haley <aph@cambridge.redhat.com> writes:
> Well, I mean it shoudn't be hard to print a list of addresses:

Where will you get that list of addresses from? =)

  - a

-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com

Re: [freenet-tech] Technology / Features

[Andrew Haley]

Andrew Haley writes:
 > Adam Megacz writes:
 >  > 
 >  > Jeff Sturm <jsturm@one-point.com> writes:
 >  > > On 25 Feb 2002, Adam Megacz wrote:
 >  > > > I personally don't use GCJ for debugging -- I get my code 100%
 >  > > > working/debugged/tested under HotSpot
 >  > 
 >  > > I find your comment a little surprising... while gdb's support for java
 >  > > has room for improvement, I've never seen a java debugger I liked.
 >  > 
 >  > I rarely use debuggers for Java code (when I do, I use jswat, which is
 >  > decent). println() and printStackTrace() are my favorite debugging
 >  > tools -- my main gripe is that gcj-win32 can't give stack traces, and
 >  > probably will never be able to.
 > 
 > No stack traces?  It shouldn't be hard.

Well, I mean it shoudn't be hard to print a list of addresses: put
that thru addr2line and you've got your stack trace.

Andrew.

Re: [freenet-tech] Technology / Features

[Andrew Haley]

Adam Megacz writes:
 > 
 > Jeff Sturm <jsturm@one-point.com> writes:
 > > On 25 Feb 2002, Adam Megacz wrote:
 > > > I personally don't use GCJ for debugging -- I get my code 100%
 > > > working/debugged/tested under HotSpot
 > 
 > > I find your comment a little surprising... while gdb's support for java
 > > has room for improvement, I've never seen a java debugger I liked.
 > 
 > I rarely use debuggers for Java code (when I do, I use jswat, which is
 > decent). println() and printStackTrace() are my favorite debugging
 > tools -- my main gripe is that gcj-win32 can't give stack traces, and
 > probably will never be able to.

No stack traces?  It shouldn't be hard.

Andrew.

Re: [freenet-tech] Technology / Features

[Adam Megacz]

Jeff Sturm <jsturm@one-point.com> writes:
> On 25 Feb 2002, Adam Megacz wrote:
> > I personally don't use GCJ for debugging -- I get my code 100%
> > working/debugged/tested under HotSpot

> I find your comment a little surprising... while gdb's support for java
> has room for improvement, I've never seen a java debugger I liked.

I rarely use debuggers for Java code (when I do, I use jswat, which is
decent). println() and printStackTrace() are my favorite debugging
tools -- my main gripe is that gcj-win32 can't give stack traces, and
probably will never be able to.


> And a core dump from the JDK is pretty much useless.

Well, if HotSpot dumps core, it's Sun's fault, not yours =)


  - a


-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com

Re: [freenet-tech] Technology / Features

[Jeff Sturm]

On 25 Feb 2002, Adam Megacz wrote:
> I personally don't use GCJ for debugging -- I get my code 100%
> working/debugged/tested under HotSpot, and then recompile with GCJ for
> deployment. VM's and interpreters will probably always provide a
> better debugging environment than static compilers.

I find your comment a little surprising... while gdb's support for java
has room for improvement, I've never seen a java debugger I liked.

With gcj I can connect to a running process and examine threads, data,
etc.  Sun's JDK doesn't provide much other than the SIGQUIT hook.  And a
core dump from the JDK is pretty much useless.

Jeff

Re: [freenet-tech] Technology / Features

[Tom Tromey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 824 bytes --]

>>>>> "Göran" == Göran Thyni <goran@kirra.net> writes:

Göran> There are some smaller issues too,
Göran> I will make test cases and file them too.

Thanks.

Göran> of course but freenet works on JDK/Jikes/Kaffe.
Göran> When I hack the code to get it to compile with gcj
Göran> it doesn't work as good. Neither does a binary compiled
Göran> from JDK generated .class files.

Göran> Could be my fault, 
Göran> could be subtle falut in the freenet code,
Göran> could be gcj/libgcj bug.

You could also try to run the .class files using `gij'.
This is helpful for determining whether you've run into a compiler
problem or runtime problem (though of course it opens the possibility
of an interpreter problem).

Anyway, in theory `gij' and `java' should have identical results.
So we're interested in divergences.

Tom

Re: [freenet-tech] Technology / Features

[Göran Thyni]

On Mon, Feb 25, 2002 at 12:29:57PM -0800, Adam Megacz wrote:
> 
> Goran Thyni <goran@kirra.net> writes:
> > It is more a question of syntax not handled by gcj at the moment.
> 
> What syntax does GCJ not handle?

The big one is that it can't inherited from an public inner class.
I filed a bug report PR-5758.
(should have check the DB more closly PR-5632 seems to be the same issue)

There are some smaller issues too,
I will make test cases and file them too.

> I personally don't use GCJ for debugging -- I get my code 100%
> working/debugged/tested under HotSpot, and then recompile with GCJ for
> deployment. VM's and interpreters will probably always provide a
> better debugging environment than static compilers.

Hmm,
of course but freenet works on JDK/Jikes/Kaffe.
When I hack the code to get it to compile with gcj
it doesn't work as good. Neither does a binary compiled
from JDK generated .class files.

Could be my fault, 
could be subtle falut in the freenet code,
could be gcj/libgcj bug.

best regards,
-- 
Göran Thyni

Re: [freenet-tech] Technology / Features

[Adam Megacz]

Mark Wielaard <mark@klomp.org> writes:
> but libgcj is still missing some of the provider/implementation
> gnu.java.security.* classes/packages.

Ah, that would explain why lots of stuff didn't work.

  - a

-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com

Re: [freenet-tech] Technology / Features

[Mark Wielaard]

Hi,

On Mon, 2002-02-25 at 19:54, Brian Jones wrote:
> 
> Unless I'm missing something, the libraries probably aren't doing
> enough of the required API level security checks that are supposed to
> be going on.  Of course, I may be wrong.  Classpath's default security
> provider does nothing anyway.  Adam could be referring to something
> else.

Also note that our java.util.jar package does not do Certificate lookups
and checking which makes it impossible for the URLClassLoader to set the
ProtectionDomain correct for classes.

Letting java.util.jar handle Certificates correctly should not be such a
big/difficult task to implement (although it is a long time ago that I
implemented that package. And there is probably a reason that I didn't
implement it back then, but maybe it was just the fact that we had no
java.security yet. I don't really remember). So if someone is looking
for a fun thing to hack on...

Cheers,

Mark

Re: [freenet-tech] Technology / Features

[Mark Wielaard]

Hi,

On Mon, 2002-02-25 at 19:41, Adam Megacz wrote:
> 
> Has java.security.* been merged with the GNU Classpath?

Yes the java.security.* classes/packages have, but libgcj
is still missing some of the provider/implementation
gnu.java.security.* classes/packages.

Also note that the Orp developers have really used some of this stuff
and submitted patches that still have to be integrated (if only I had
time...) http://savannah.gnu.org/patch/download.php?id=69

Cheers,

Mark

Re: [freenet-tech] Technology / Features

[Adam Megacz]

Brian Jones <cbj@gnu.org> writes:
> Adam could be referring to something else.

Actually that was back when I was trying to use the Cryptix provider
under GCJ in order to use PureTLS. I ran into a sieres of bugs which
led me to believe that whoever wrote libgcj's java.security.* had
never tested it with anything other than the default provider.

At that point I became immensely frustrated and embarked on a five-day
coding binge during which I implemented SSLv3 from the spec, using the
SHA1/MD5/RSA/RC4/x509 primitives in BouncyCastle, which thankfully
doesn't require you to go through the java.security.* nonsense to do
something as simple as 'RSA-decrypt this byte[] using this pair of
java.math.BigInteger's as the key'.

I'm still totally blown away by the performance difference between
HotSpot and GCJ on stuff like this... I can only assume that this yet
another benefit of using the GCC optimizer/backends. I don't think I
was even using -O2 or -fno-bounds-check.

  - a

-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com

Re: [freenet-tech] Technology / Features

[Tom Tromey]

>>>>> "Adam" == Adam Megacz <gcj@lists.megacz.com> writes:

Adam> Has java.security.* been merged with the GNU Classpath?

Yes.  I think it was one of the first things merged.

Tom

Re: [freenet-tech] Technology / Features

[Adam Megacz]

Goran Thyni <goran@kirra.net> writes:
> It is more a question of syntax not handled by gcj at the moment.

What syntax does GCJ not handle?

> A way around syntax problems is to just compile .class files
> generate by jikes/javac with gcj. But this is no fun debugging.

I personally don't use GCJ for debugging -- I get my code 100%
working/debugged/tested under HotSpot, and then recompile with GCJ for
deployment. VM's and interpreters will probably always provide a
better debugging environment than static compilers.

  - a

-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com

Re: [freenet-tech] Technology / Features

[Tom Tromey]

>>>>> "Brian" == Brian Jones <cbj@gnu.org> writes:

Brian> Unless I'm missing something, the libraries probably aren't
Brian> doing enough of the required API level security checks that are
Brian> supposed to be going on.

Ok, thanks.  I know we need to do this kind of security audit of the
sources.  I haven't filed a PR though -- bad me.

Tom

Re: [freenet-tech] Technology / Features

[Goran Thyni]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

On Mon, Feb 25, 2002 at 09:31:56AM -0800, Adam Megacz wrote:
> What's missing? Crypto- and network-wise, I've gotten a full SSL
> implementation running under GCJ (http://www.xwt.org/tinyssl).

freenet has all crypto code it needs in itself.
It is more a question of syntax not handled by gcj
at the moment.
 
> You can also run Sun's bytecodes through GCJ (for example, to replace
> libgcj's broken java.security.*), but the resulting binary probably
> can't be redistributed.

A way around syntax problems is to just compile .class files
generate by jikes/javac with gcj. But this is no fun debugging.

> I've also found that GCJ kicks the crap out of HotSpot on crypto
> operations. For example, TinySSL's RSA handshake runs literally ten
> times faster on the same hardware (BouncyCastle crypto library).

Sound good.

happy hacking,
---
Göran


[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: [freenet-tech] Technology / Features

[Adam Megacz]

Tom Tromey <tromey@redhat.com> writes:

> (I didn't know our java.security had any problems...).  Thanks.

Okay, I'll try to reproduce a test case.

Has java.security.* been merged with the GNU Classpath?

  - a

-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com

Re: [freenet-tech] Technology / Features

[Brian Jones]

Tom Tromey <tromey@redhat.com> writes:

> >>>>> "Adam" == Adam Megacz <gcj@lists.megacz.com> writes:
> 
> Adam> You can also run Sun's bytecodes through GCJ (for example, to replace
> Adam> libgcj's broken java.security.*), but the resulting binary probably
> Adam> can't be redistributed.
> 
> Please file bug reports about what you know to be broken in
> java.security.  It's important to do this because you might be the
> only person to know about any given bug (I didn't know our
> java.security had any problems...).  Thanks.

Unless I'm missing something, the libraries probably aren't doing
enough of the required API level security checks that are supposed to
be going on.  Of course, I may be wrong.  Classpath's default security
provider does nothing anyway.  Adam could be referring to something
else.

Brian
-- 
Brian Jones <cbj@gnu.org>

Re: [freenet-tech] Technology / Features

[Tom Tromey]

>>>>> "Adam" == Adam Megacz <gcj@lists.megacz.com> writes:

Adam> You can also run Sun's bytecodes through GCJ (for example, to replace
Adam> libgcj's broken java.security.*), but the resulting binary probably
Adam> can't be redistributed.

Please file bug reports about what you know to be broken in
java.security.  It's important to do this because you might be the
only person to know about any given bug (I didn't know our
java.security had any problems...).  Thanks.

Adam> I've also found that GCJ kicks the crap out of HotSpot on crypto
Adam> operations. For example, TinySSL's RSA handshake runs literally ten
Adam> times faster on the same hardware (BouncyCastle crypto library).

Nice.  BouncyCastle is in rhug, so building it should be pretty easy
for anybody interested.

Tom

Re: [freenet-tech] Technology / Features

[Adam Megacz]

G?ran Thyni <goran@kirra.net> writes:
> I use pre-3.1 CVS snapshots for my experiments with freenet and gcj.
> 3.1 is much better then 3.0 BUT at this time it is still not up to
> the task of compiling freenet out-of-the-box.

What's missing? Crypto- and network-wise, I've gotten a full SSL
implementation running under GCJ (http://www.xwt.org/tinyssl).

You can also run Sun's bytecodes through GCJ (for example, to replace
libgcj's broken java.security.*), but the resulting binary probably
can't be redistributed.

I've also found that GCJ kicks the crap out of HotSpot on crypto
operations. For example, TinySSL's RSA handshake runs literally ten
times faster on the same hardware (BouncyCastle crypto library).

  - a

--
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Re: [freenet-tech] Technology / Features

[Tom Tromey]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

>>>>> "Göran" == Göran Thyni <goran@kirra.net> writes:

Göran> 3.1 is much better then 3.0 BUT at this time it is still not up to
Göran> the task of compiling freenet out-of-the-box.

Please report all bugs to the gcc Gnats database.  I can't promise
we'll fix them all in time for any particular release, but we
definitely want to be able to track them.  We're definitely interested
in making gcj able to correctly compile all Java code, and especially
free code.

Tom

Re: [freenet-tech] Technology / Features

[Göran Thyni]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

On Sun, Feb 24, 2002 at 10:07:59PM +0000, Gordan Bobic wrote:
> 4) Would it be possible for the GCJ compiled binaries to be made available 
> for Linux/FreeBSD in addition to the daily .jar image? Most distributions 
> still do not come with GCC v3, and even for those that do, latest snapshots 
> of GCC/GCJ v3 seem to be required to make things work. Since the CVS snapshot 
> seems to have the required Makefile sections for GCJ building, it would be 
> VERY nice to have a downloadable statically linked binary available for 
> download. A dynamically linked binary with a sufficiently up-to-date GCJ 
> library would be even nicer, even if it is without any sort of fancy 
> packaging.

As other answered: no, not as this time.
I use pre-3.1 CVS snapshots for my experiments with freenet and gcj.
3.1 is much better then 3.0 BUT at this time it is still not up to
the task of compiling freenet out-of-the-box.
3.1 is scheduled for release in April so I doubt all the fixes needed
will be in that one.
Compilers are complicated things but I (we) can do a bit to help
the development, at least by reporting bugs to the GCC team. 
The Freenet codebase is a great testbed for a Java compiler.

Hopefully release 3.2 scheduled for September 2002 is feature
complete enough to make a stable gcj compiled freenet node
possible.

Here is the plan for GCC releases:
http://gcc.gnu.org/develop.html

I CC:ed this to java@gcc.gnu.org to perhaps get some comments from
the GCJ developers.

regards,
-- 
Göran Thyni
talvimaa





[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]