> Date: Fri, 16 Jul 1999 10:49:47 -0500
> From: Jim Kimball <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
>
> It was my understanding that code wrapped in an exception handler
> introduces more overhead to the JVM. I am sure I have seen articles on
> this exact topic in Java World or Java Report.
>
> Jim
>
> Dimitris Vyzovitis wrote:
> >
> > SHUDO Kazuyuki wrote:
> >
> > > > Personally I prefer explicit checks.
> > >
> > > Why?
> > >
> >
> > I am also tempted to ask why....
> > Is there any particular reason to add client side check for what the VM does on
> > its own?
> > I personally think that there is no need to do explicit checks in your code
> > (it is inherently suboptimal) and let the VM do its work - just add the
> > required exception handlers ;-}.
> >
> > -- dimitris
> >
>
> --
> =====================================================================
> Jim Kimball
Oops. I've created confusion. When I said "Personally I prefer
explicit checks" I was NOT saying that you should write code like
this:
void foo(Point p) { // (1)
if (p != null) {
p.x = 10;
}
}
You should write
void foo(Point p) { // (2)
p.x = 10;
}
[
[While we are on the topic another variant is:
void foo(Point p) { // (3)
try {
p.x = 10;
} catch (NullPointerException npe) {
// pretty message about the validity of p
}
}
I've seen people do (3) in real code. Personally, I think (3)
is ugly and redundant with Java (don't confuse this personal
preference with the other personal preference about explicit
checks).
]
Back to the original topic. Lets all agree that best way to write
Java code is (2). Then the VM/JIT (note: NOT you the programmer) has
to do the check anyway (if p is null, I am the VM, and I better raise
a null pointer exception when p.x is tried). One way to do this in a
JIT is to generate code that tests p != null.
(a) explicit check intel assembly for (2)
movl 12(%ebp), %eax ; iload_0, ie, handle for p in eax
andl %eax, %eax ; is handle 0?
jne not_null
pushl $9 ; 9 is a const denoting NPE
call raise_exception
not_null:
movl (%eax), %eax ; eax = handle->obj
movl $10, %(eax) ; handle->obj->x = 10
(b) implicit check intel assembly for (2)
movl 12(%ebp), %eax ; iload_0, ie, handle for p in eax
movl (%eax), %eax ; eax = handle->obj (note **)
movl $10, (%eax) ; handle->obj->x = 10A
note **: if eax is zero, (%eax) will SEGV, and control jumps
to signal handler, which will figure out if the SEGV
happened in JIT generated code, and raise a NPE
You can now see why implicit check has a performance advantage.
However (a) doesn't have any complicated code in signal handlers--this
is why I said I prefer explicit checks as a VM hacker (makes debugging
easier, OS ports are easier).
Coupla thoughts on this:
- HotSpot doesn't do
load handle address; load object address; load field address; read
It simply does
load object address; load field address, read
because it is a handle-less VM.
- This doesn't mean that your Linux sunwjit is generating code all the
time with twice as many instructions (or half as slow) as the
Solaris sunwjit. Remember the checks are for getfield, putfield,
invoke* opcodes. And the check is only on the first access of a
object. That is "p.x = 10; p.y = 20;" should check p's nullness
only once.
-Anand.
PS:
> It was my understanding that code wrapped in an exception handler
> introduces more overhead to the JVM.
This might not be true any longer. Links to the article, anyone?
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
