JDK-4632854 : java -server generates a lot of signals
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.3.1,1.4.0,1.4.0_01
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris,solaris_8
  • CPU: sparc
  • Submitted: 2002-02-04
  • Updated: 2022-04-05
  • Resolved: 2002-10-17
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 mantisFixed
Related Reports
Duplicate :  
Relates :  
Description
Pl. see comments.

Added numbers from run with -client, pl. see comments

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis
14-06-2004

EVALUATION This should be addressed in 1.4.1 Running ECPerf on a 1.4 I am seeing a bit less that 2 SEGV's per second. This is about half the rate that was seen by the submitter in a 1.3.1 VM. I believe that 2 SEGV's per second would be having at most a very negligible effect on the performance of ECPerf. However I have investigated where they are coming from. The other two signals mentioned, SIGILL and SIGUSR1 occur at least 50 times less frequently so I am not going to worry about them. I suspected that the majority of the SEGV's were coming from implicit null checks in C2 generated code. This was confirmed by running ECPerf with an option which disabled the implicit null checks. The number of SEGV's decreased by 97%. Implicit null checks (which cause a SEGV if they fail) should only be generated for checks which had never seen a null during interpreter execution. We should be seeing almost no SEGV's caused by the implicit checks. Either there is a significant change in behavior later so that the null checks start to fail, or there is a bug in the way we determine whether to generate an implicit check (probably bad interpreter profile information.) I will investigate further to determine the cause of the SEGV's. ###@###.### 2002-03-06 My previous evaluation was incorrect. We don't collect statistics about implicit null pointer exceptions in the interpreter, only about null pointer checks which are done explicitly in the bytecodes (as part of the normal branch profiling.) I determined that the overhead of recording null pointer exceptions (NPE's) on a per-bytecode basis would be too great. The MethodData information would have to maintain statistics on all of the array load, array store, getfield, putfield and invocation bytecodes, most of which we don't track now. Instead, since we expect NPE's to be pretty rare, I decided to record the number thrown in the entire method during interpreter execution. This information was then used by the server compiler to determine whether an implicit, or explicit null check would be generated. This change gave a 2% improvement in the ECPerf score. ###@###.### 2002-10-08
08-10-2002