Native Derby?

[Steve Stewart <st...@canada.com>]

Hi folks,

Whether it was UCSD Pascal, Java, or whatever, I never much
liked the idea of virtual machines hogging memory and
intermediate bytecode being compiled every time it executes.
Garbage collection never seems to be very reliable, among
other things.

Now that Fedora, for example, ships with native Eclipse and
Tomcat compiled with gcj, I wonder what the prospects are
for a native Derby?

I realize Derby requires, for instance, a JDBC client, which
relies, in turn, on java.sql and javax.sql, but isn't the
FSF Classpath Project already addressing such issues?

Yours truly,
STEWART & CIE.

Steve Stewart


----------------------------------------
Upgrade your account today for increased storage; mail
forwarding or POP enabled e-mail with automatic virus
scanning. Visit
http://www.canada.com/email/premiumservices.html for more
information.

Re: Native Derby?

[Dy...@Sun.COM]

Steve Stewart <st...@canada.com> writes:

> Hi folks,
>
> Whether it was UCSD Pascal, Java, or whatever, I never much
> liked the idea of virtual machines hogging memory and
> intermediate bytecode being compiled every time it executes.

I know what you mean, and I understand your concern. Having said that,
I think Derby is better than many other Java apps out there. At least
that has been my experience.

> Garbage collection never seems to be very reliable, among
> other things.

I have profiled Derby (running TPC-B like load) and the gc graphs
showed that a running Derby system spends very little time doing
gc. My understanding is that this is by design.

> Now that Fedora, for example, ships with native Eclipse and
> Tomcat compiled with gcj, I wonder what the prospects are
> for a native Derby?

I guess you have already seen a posting from someone wanting to do
this. It is an interesting idea and I hope they succeed. It would be
interesting to see what kind of benefits it would give. 

The conventional wisdom is that in database system the cost of
starting the jvm and getting the full effect of HotSpot compilation
can be ignored since the system is expected to run for a long
time. And then the benefit of compiling everything to native code
would be marginal. But this assumption may not necessarily hold for all
applications that would like to embed Derby...

> I realize Derby requires, for instance, a JDBC client, which
> relies, in turn, on java.sql and javax.sql, but isn't the
> FSF Classpath Project already addressing such issues?

Could be, I don't know :) Do you have an URL?

-- 
dt

However, experience shows that for many people and many applications a
dose of paranoia is reasonable - Bjarne Stroustrup