public inbox for java-prs@sourceware.org help / color / mirror / Atom feed
From: "tromey at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: java-prs@gcc.gnu.org Subject: [Bug java/21856] New: null pointer check elimination Date: Wed, 01 Jun 2005 01:58:00 -0000 [thread overview] Message-ID: <20050601015824.21856.tromey@gcc.gnu.org> (raw) 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
next reply other threads:[~2005-06-01 1:58 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2005-06-01 1:58 tromey at gcc dot gnu dot org [this message] 2005-06-01 20:29 ` [Bug java/21856] " pinskia at gcc dot gnu dot org 2005-06-03 14:08 ` dnovillo at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20050601015824.21856.tromey@gcc.gnu.org \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=java-prs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).