harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Etienne Gagnon <egag...@sablevm.org>
Subject Re: NullPointerException
Date Mon, 20 Mar 2006 17:43:16 GMT
Adding my opinion to the pool of opinions...

There are 2 basic approaches used in simpler JVMs (interpreters, simple
JITs) to check for null pointers: a) explicit check, and b) operating
system signals on invalid memory access.  Usually, simpler systems pick
one of these two approaches and stick to it.

On more advanced JVMs (adaptive systems such as HotSpot and Jikes RVM),
 the JVM reacts to the behavior of executed code.  So, possibly, the JVM
would start using os signals first, yet, if a signal is actually raised,
the JVM will re-compile and re-optimize the culprit code that raised the
signal to add an explicit null check.

So, IMO, the current debate is a no-debate.  People that use an
interpreter or a simple JIT are obviously not looking for
"high-performance", so trying to save a bytecode or two, or trying to
make exceptions run as fast as possible is not really relevant.  On the
other hand, adaptive JVMs can actually adapt to the best strategy during
execution, and thus adding an explicit check or not in the source code
will probably make no difference whatsoever.  [Adaptive systems go as
far as not creating the exception object when they determine that it is
safe to do so...]

So, my vote goes in the direction of: write what is best for maintenance
of the class library source code, not what you think will be fastest for
execution on a JVM, as it is difficult to clearly identify the later.



Jeroen Frijters wrote:
> Mikhail Loenko wrote:
>>My experiments have shown that additional check for null is 
>>insignificant while accessing time of a null address is
> That in itself is not enough to base any conclusions on. You also need
> to know the ratio between the exception between thrown and not being
> thrown.
> The extra bytecode (or jitted machine code) may very well cause
> additional paging (due to increased memory pressure) and that has to be
> factored in as well.
> Regards,
> Jeroen

Etienne M. Gagnon, Ph.D.            http://www.info2.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

View raw message