Sometimes we emit explicit null pointer checks. On some platforms we
do this for every member reference; many of these should be trivial to
eliminate. On x86 Linux, we only do this in one special case, which
is checking the 'this' argument to a final method call with the non-BC
ABI.
Here's a test case:
public class z
{
public final void m() { System.out.println("m"); }
public void nothing() { }
public static void main(String[] args)
{
z val = new z();
val.nothing();
val.m();
}
}
When I compile this with -S ("gcj -O0 -S z.java"), I see an explicit
check and conditional call to _Jv_ThrowNullPointerException before the
`val.m()' invocation. However, we know that this is redundant, as
'val.nothing()' would have thrown if val==null.
The situation here may be complicated by the fact that a java program
can catch NullPointerException. In this test case, it is invalid to
optimize away the check when val.m() is called:
public abstract class z
{
public final void m() { System.out.println("m"); }
public void nothing() { }
public abstract z get_one();
public static void main(String[] args)
{
z val = get_one();
try {
val.nothing();
} catch (NullPointerException _) {
}
val.m();
}
}
One more wrinkle in this area is that on some platforms (all the
well-supported ones like x86 Linux), we do not emit explicit null
checks. Instead we just let them SEGV and at runtime convert this
into an exception. On these platforms we compile java code with
flag_non_call_exceptions=1.
However, I would expect we could get better optimizations later on if
we could notice that some of these references can never be made via a
null base pointer. For this to work, I think there would have to be a
way to tell RTL about the difference between a possibly-trapping and a
never-trapping load. I know basically zero about RTL so I don't know
if this is realistic at this point.
If you compile the two "z.java" test cases for some
less-well-supported target, you will see explicit null pointer checks
at each call site. I'm not sure if we emit tests for references via
'this' -- I think we have an ad hoc optimization for it.
Another thing we can recognize is that 'new' never returns null. We
set DECL_IS_MALLOC on the function we use to create objects and
arrays, though I suppose that wouldn't suffice. These functions are
declared in decl.c, just search for DECL_IS_MALLOC there (there are a
few instances). I don't know of a way for the front end to inform
later passes about this property of 'new'.
--
Summary: null pointer check elimination
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: dnovillo at redhat dot com
ReportedBy: tromey at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21856
