public inbox for java-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug java/21856] New: null pointer check elimination
@ 2005-06-01  1:58 tromey at gcc dot gnu dot org
  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
  0 siblings, 2 replies; 7+ messages in thread
From: tromey at gcc dot gnu dot org @ 2005-06-01  1:58 UTC (permalink / raw)
  To: java-prs

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


^ permalink raw reply	[flat|nested] 7+ messages in thread
[parent not found: <bug-21856-360@http.gcc.gnu.org/bugzilla/>]
[parent not found: <bug-21856-8172@http.gcc.gnu.org/bugzilla/>]
end of thread, other threads:[~2013-10-11 11:48 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-06-01  1:58 [Bug java/21856] New: null pointer check elimination tromey at gcc dot gnu dot org
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
     [not found] <bug-21856-360@http.gcc.gnu.org/bugzilla/>
2005-11-12 20:08 ` pinskia at gcc dot gnu dot org
2005-11-12 20:09 ` pinskia at gcc dot gnu dot org
2006-01-09 18:34 ` pinskia at gcc dot gnu dot org
     [not found] <bug-21856-8172@http.gcc.gnu.org/bugzilla/>
2013-10-11 11:48 ` glisse at gcc dot gnu.org

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).