JDK-5059669 : Can not eliminate implicit null checks for method invocations based on profile
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2_04
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: x86
  • Submitted: 2004-06-08
  • Updated: 2004-08-17
  • Resolved: 2004-07-13
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2_06 06Fixed
Related Reports
Relates :  
JDK-4632854 - java -server generates a lot of signals
Description
Observed many SEGV/FLTBOUNDS signals generated from JVM in running benchmark for
Java application of ISV and those signals seem to be related to few methods.
So, it may be possible to boost the performance by implementing JVM
as more suitable for the application.
The benchmark environment is v20z/Solaris9/Java_1.4.2_04.

[SEGV]

The Java application is huge cpu intensive one and tried truss to JVM running
the application. Then, saw huge number of SEGV in the truss output, 
it's about 6000 in about 80 seconds running.

truss -c -p 18000
^Cfaults -------------
FLTBOUNDS       6332
total:          6332

signals ------------
SIGSEGV         6332
total:          6332
<snip>

[NullPointerException]

And guess the SEGV/FLTBOUNDS cames from Null Checking mechanism for NullPointerException
then tried java studio debugger to identify where NullPointerException is generated
and found only few methods are related to the exception.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_06 generic tiger-rc FIXED IN: 1.4.2_06 tiger-rc INTEGRATED IN: 1.4.2_06 tiger-b58 tiger-rc
18-08-2004
EVALUATION In most cases, implicit null checks provide a performance benefit by elimating the extra instructions needed for a null pointer check. This works well when NullPointerExceptions are extremely rare in the running of a Java application (which is usually the case.) However the overhead of handing the SEGV can hurt performance if NullPointerExceptions occur more often. The compiler deals with this by not generating implicit if the number of NullPointerExceptions seen in a method exceeds a threshold (see bugid 4632854.) However this was not being done for null checks on method invocations. The fix was to add an explicit null check for method invocations if appropriate. ###@###.### 2004-06-08
08-06-2004