--- Knut Anders Hatlen <[EMAIL PROTECTED]> wrote:
> craig vanderborgh <[EMAIL PROTECTED]> 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/
