sunwjit, symcjit and even hotspot do "implicit exceptions." Meaning a
null pointer exception is detected from a SIGSEGV, and the VM raises
the related NullPointerExcetion from the signal handler. This offers
the best performance for the normal case where there isn't a NPE. In
general, doing control flow through exceptions is a bad idea (because
of the machinery required to find the handler, and also because Java's
design requires stack traces to be filled into an exception object at
the time of creation). Exceptions are for exceptional circumstances.
That said, the sunwjit port of Linux does NOT do implicit exceptions.
There is a lot of code in the JIT that generates machine code that
explicitly tests for NPEs, StackOverflows, ArithmeticExceptions. So
if you compared the performance of sunwjit or Solaris vs. sunwjit on
Linux, the Solaris one will be slightly ahead (I haven't measured
exactly how much).
Personally I prefer explicit checks. But an ex-Self person (and now
HotSpot person) once told me that explicit checks in the Self system
cost about 5-10% in performance depending on the application you are
running.
-Anand.
> Date: Sun, 11 Jul 1999 15:18:34 -0700
> From: Nathan Meyers <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
>
> I ran into this tidbit today in some Sun online training material on
> JDK1.2:
>
> > The JIT compiler also achieves a minor performance gain by not pre-checking
>certain Java
> > boundary conditions such as Null pointer or array out of bounds exceptions. The
>only way
> > the JIT compiler knows it has a null pointer exception is by a signal raised by
>the operating
> > system. Because the signal comes from the operating system and not the Java VM,
>your
> > program takes a performance hit. To ensure the best performance when running an
> > application with the JIT, make sure your code is very clean with no errors like
>Null pointer or
> > array out of bounds exceptions.
>
> I suppose this is describing the sunwjit compiler, and not a general
> condition that JITs are required to handle. But it does seem a bit
> dicey, relying on signals to detect conditions that might not raise a
> signal, and -- relevant to the Blackdown porting challenges -- relying
> on a mechanism that seems to be very troublesome in the Linux
> multi-threaded environment.
>
> Has this JIT feature been causing any problems in the Blackdown port?
>
> Nathan Meyers
> [EMAIL PROTECTED]
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
