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