-----Original Message----- From: Ulrich Kunitz [mailto:[EMAIL PROTECTED] Sent: Wednesday, 25 May 2005 7:55 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] 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. Cheers, Daniel.
