From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8497 invoked by alias); 1 Jun 2005 01:58:31 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 8333 invoked by uid 48); 1 Jun 2005 01:58:29 -0000 Date: Wed, 01 Jun 2005 01:58:00 -0000 From: "tromey at gcc dot gnu dot org" To: java-prs@gcc.gnu.org Message-ID: <20050601015824.21856.tromey@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug java/21856] New: null pointer check elimination X-Bugzilla-Reason: CC X-SW-Source: 2005-q2/txt/msg00645.txt.bz2 List-Id: 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