db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: Native Derby?
Date Wed, 30 Nov 2005 09:24:01 GMT
Steve Stewart <stewartetcie@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?


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

View raw message