Remove the assert in Integer.valueOf() (original) (raw)

Alex Lam S.L. alexlamsl at gmail.com
Mon Apr 23 22:32:41 UTC 2012

Just curious - I am assuming that assertions are disabled during the test runs, so wouldn't one expect the "assert" statements to be ignored / removed?

Obviously it didn't in this case, yet I thought we are expecting constant conditionals to be optimised, e.g. if (a == null) {...} to be removed if "a" can never be null?

Alex.

On Mon, Apr 23, 2012 at 7:01 PM, Rémi Forax <forax at univ-mlv.fr> wrote:

On 04/23/2012 07:43 PM, Mario Torre wrote:

2012/4/23 Rémi Forax<forax at univ-mlv.fr>:

The issue is that Hotspot also count the bytecodes related to assert in its inlining heuristic. If the assert is commented, the inlining tree is good. [...] Given that Integer.valueOf() is a method used very often and that if the inlining fails, the escape analysis will not remove the allocation, I think it's a good idea to comment this assert. Hi Rémi, I'm not sure if it's a good idea or not to remove the assert. What happens if we replace the assert with a specific check, is it still not inlined? Cheers, Mario Hi Marrio, if you add a check, you augment the size of the bytecode and unluckily the Hostspot inlining heuristic is based on the size of the bytecode. I've also forgotten to mention that this assert is useless given the code the static block of Integer.IntegerCache. static final int low = -128;  static final int high; static {  // high value may be configured by property  int h = 127;  String integerCacheHighPropValue =  sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");  if (integerCacheHighPropValue != null) {  int i = parseInt(integerCacheHighPropValue);  i = Math.max(i, 127);  // Maximum array size is Integer.MAXVALUE  h = Math.min(i, Integer.MAXVALUE - (-low));  }  high = h;  ...  } cheers, Rémi

More information about the core-libs-dev mailing list