Hi, Michal!
You wrote:
> Hi Igor,
>
> > ---- Ian wrote:
> > > I agree, however, the explicit null check will slow
> > > down the execution speed of applets.
> >
> > Why? In case of a JIT or compiled Java for applets "if (sm !=
> > null)" will be branch predicted and cause no harm at all.
> > Moreover, AFAIK try/catch in general produce more code and
> > even if it is never executed it still can cause more
> > processor cache misses.
>
> We're still talking about the scenario in which the reference is very rarely
> null, right?
>
> Try/catch may indeed produce more code, but it will be distributed unevenly.
> The hot path ("sm!=null") will be shorter (because there's no check), but
> the cold path (with the exception handler) will possibly become longer. Any
> good JIT compiler will put cold and hot code away from each other, so in the
> common case we should have fewer cache misses if we use the OS to catch null
> pointer exceptions.
>
Ok, I agree that cache misses with this policy is not that important although `if (sm
!= null)' produces less code which means shorter load time. And still, what about
branch prediction? Does it good enough to make `if (sm != null) code' run as fast as
`code' when `sm != null' is always true thus nullifying ANY reason to use try/catch
hack?
Regards, Igor
------------------------------------------------------
Get the Latest News at CNN Interactive: http://CNN.com
