db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From craig vanderborgh <craigulus5...@yahoo.com>
Subject Re: Derby on GCJ
Date Wed, 30 Nov 2005 16:12:28 GMT

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

> craig vanderborgh <craigulus5000@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.

craig vanderborgh
voxware incorporated

> -- 
> Knut Anders

Yahoo! Music Unlimited 
Access over 1 million songs. Try it free. 

View raw message