User account creation filtered due to spam.

Bug 17187 - Call to java.lang.Object constructor is redundant
Summary: Call to java.lang.Object constructor is redundant
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.0.0
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: missed-optimization
Depends on:
Reported: 2004-08-25 15:45 UTC by Bryce McKinlay
Modified: 2016-09-30 22:52 UTC (History)
3 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2006-04-23 18:03:27


Note You need to log in before you can comment on or make changes to this bug.
Description Bryce McKinlay 2004-08-25 15:45:47 UTC
The constructor for java.lang.Object does nothing. Its probably a reasonable
assumption that it will always do nothing, so, we should change the compiler to
not generate calls to it when generating native code. This would save 1 call for
every "new" operation, and also improve the number of inlining opportunities
available to the compiler, as many constructor calls could now be fully inlined.

One way to do this might be to extend the java "builtins" mechanism to allow us
to  turn other well known calls, not just Math.* calls, into inlined trees. If
we see a java.lang.Object() call, check_for_builtin() would just return an empty
statement tree.
Comment 1 Andrew Pinski 2004-08-25 15:58:47 UTC
Confirmed.  But I should note that even the Sun's javac does not do this optimization so ...
Comment 2 Bryce McKinlay 2004-08-25 16:16:33 UTC
pinskia: bytecode compilation is a different story. Obviously we should only do
this when compiling to _native_ code. We know our java.lang.Object constructor
doesn't do anything, but we can't make that assumption about other implementations.
Comment 3 Andrew Pinski 2004-11-08 02:49:27 UTC
Man this is a semi hard problem, I could figure out where the call expression is built but we patch it up 
which makes it harder (maybe we should pass a pointer to the tree which we patch up and then change 
it to a nop).
Comment 4 Andrew Pinski 2016-09-30 22:52:22 UTC
Closing as won't fix as the Java front-end has been removed from the trunk.