harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: NullPointerException
Date Tue, 21 Mar 2006 02:28:07 GMT
Etienne Gagnon wrote:
> 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.
> :-)
> Etienne
> 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
>>> substantial.
>> 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

Paulex Yang
China Software Development Lab

View raw message