Derby on GCJ

[craig vanderborgh <cr...@yahoo.com>]

Hello,

We are going to make a substantial attempt to get Derby running on GCJ.  The
goal is not to run Derby on the GCJ "JVM", but instead to ahead-of-time compile
all the Derby sources (to .o files using the gcj compiler) so that the results
are compact and fast enough to use on embedded systems.

We plan on using GCJ 3.3.2, or perhaps 4.x.  What are the primary porting
issues we're likely to encounter, and how do you think we ought to address them
in a way that might eventually be of use to the Derby project?

Please advise.

Thanks in advance,
craig vanderborgh
voxware incorporated


		
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs

Re: Derby on GCJ

[craig vanderborgh <cr...@yahoo.com>]

--- Knut Anders Hatlen <Kn...@Sun.COM> wrote:

> craig vanderborgh <cr...@yahoo.com> writes:
> 
> > Hello,
> >
> > We are going to make a substantial attempt to get Derby running on GCJ. 
> The
> > goal is not to run Derby on the GCJ "JVM", but instead to ahead-of-time
> compile
> > all the Derby sources (to .o files using the gcj compiler) so that the
> results
> > are compact and fast enough to use on embedded systems.
> >
> > We plan on using GCJ 3.3.2, or perhaps 4.x.  What are the primary porting
> > issues we're likely to encounter, and how do you think we ought to address
> them
> > in a way that might eventually be of use to the Derby project?
> 
> I haven't used GCJ myself. Does it support a mixed environment with
> some byte-compiled code and some native code? If it doesn't, I guess
> you will have trouble with the byte-code generation in the SQL
> compiler.

Yes, it most certainly does.  One of GCJ's primary advantages over the Sun(tm)
JVM(tm) is that it allows you to choose any blend of interpreted/native code
you desire.  If you're running on a honking 3GHZ PIV you would not ever care
about this.  But if you're running on a puny Xscale Windows CE drop-kickable
this is a very big deal indeed.

The performance of GCJ on code compiled to "native" is on a par with the
performance you'd expect from C++ object code.  This puts GCJ into a very
different performance league than Sun's JVM.

Regards,
craig vanderborgh
voxware incorporated

> 
> -- 
> Knut Anders
> 
> 



		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free. 
http://music.yahoo.com/unlimited/

Re: Derby on GCJ

[Knut Anders Hatlen <Kn...@Sun.COM>]

craig vanderborgh <cr...@yahoo.com> writes:

> Hello,
>
> We are going to make a substantial attempt to get Derby running on GCJ.  The
> goal is not to run Derby on the GCJ "JVM", but instead to ahead-of-time compile
> all the Derby sources (to .o files using the gcj compiler) so that the results
> are compact and fast enough to use on embedded systems.
>
> We plan on using GCJ 3.3.2, or perhaps 4.x.  What are the primary porting
> issues we're likely to encounter, and how do you think we ought to address them
> in a way that might eventually be of use to the Derby project?

I haven't used GCJ myself. Does it support a mixed environment with
some byte-compiled code and some native code? If it doesn't, I guess
you will have trouble with the byte-code generation in the SQL
compiler.

-- 
Knut Anders

Re: Derby on GCJ

[Dy...@Sun.COM]

craig vanderborgh <cr...@yahoo.com> writes:

> Hello,
>
> We are going to make a substantial attempt to get Derby running on GCJ.  The
> goal is not to run Derby on the GCJ "JVM", but instead to ahead-of-time compile
> all the Derby sources (to .o files using the gcj compiler) so that the results
> are compact and fast enough to use on embedded systems.

As I said in my reply to Steve Stewart: A really cool idea! I would really
like to compare the performance of a native Derby to one running
inside a JVM. 

>
> We plan on using GCJ 3.3.2, or perhaps 4.x.  What are the primary porting
> issues we're likely to encounter, and how do you think we ought to address them
> in a way that might eventually be of use to the Derby project?
>
> Please advise.

Can't give much. But read Steve's post (if you haven't already done
so), especially what he says about the FSF Classpath project.

-- 
dt