harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Frampton" <u3293...@anu.edu.au>
Subject RE: Terminology etc
Date Wed, 25 May 2005 03:08:13 GMT
-----Original Message-----
From: Ulrich Kunitz [mailto:kune@deine-taler.de]
Sent: Wednesday, 25 May 2005 7:55 AM
To: harmony-dev@incubator.apache.org; Steve.Blackburn@anu.edu.au
Subject: Re: Terminology etc

> ...

> But it might still be that C-implemented modules (particularly the GC)
are faster than their Java-implemented counterparts, because they ignore
array-index-checking, don't need write barriers and interface calls,
etc... One could follow the strategy, that modules must support Java
interfaces but might be implemented in C. This strategy would bring us
back to an design that doesn't mandate which language has to be used to
implement a certain module.

My instinct would be that the cost of the bounds and null checks within
the GC would be relatively insignificant. Putting that aside, it would be
possible for us to disable some checks within VM code for release builds
(leaving them in for debug builds). While I would suggest the best
approach is to leave them in always, allowing their removal would
eliminate the issue of null/bounds checking as an argument against Java.
And after we have implemented things and measured performance differences
we can make an informed decision. Naturally this would impact coding style
choices but for a bunch of VM code I wouldn't expect that we would want to
be throwing and catching exceptions in the normal course of things anyway.
It is a different story for the libraries however, and we should be very
wary of any place (if any) that we decide to remove these checks.


View raw message