JDK-6445664 : Eliminate remaining performance penalty for using assert
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6,9,10
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: generic
  • CPU: generic
  • Submitted: 2006-06-30
  • Updated: 2019-10-12
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
tbdUnresolved
Related Reports
Duplicate :  
Relates :  
Description
Core library maintainers should be encouraged to use assert,
so that more bugs could be found running tests with -esa.
However, library maintainers are reluctant to do this because of
lingering Fear Uncertainty and Doubt that their performance-critical
code will run a little slower.

One concern is the inlining threshold, which is based on the size of
methods based on bytecode, which does not take into account code which 
is dead because it is conditional on a static final boolean.

So library code maintainers fiddle with various inlining and "out"-lining
strategies for static final booleans and asserts.

private static final boolean flag = ....;

void m() { if (flag} { ... } else { ... } }
or
void m1() { ... } void m2() { ... } void m() { if (flag) m1(); else m2(); }

A compiler-maintainer-oriented way of expressing this request is:
before any method's size as measured in bytecodes is used
for inlining heuristics, make sure a dead-code elimination pass
that takes final static booleans (or ints?) into account should
be used to derive a better size for using with inlining heuristics.

Another issue is the startup cost for computing asserts.
Each class containing an assert runs a bit of code to initialize the
synthetic static final boolean via a jni call.  If every class in the JDK
did this, this cost might be significant.  Even if the cost is small, the
cost is borne by every Java program that uses those classes, which, in the
case of some core classes, means every Java program period.

Comments
It would be sufficient to tune inlining policy to ignore bytecodes which appear never to be executed, and branches that don't branch. See also discussion in JDK-6316156.
23-04-2015