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 <fo...@univ-mlv.fr> wrote:
> On 04/23/2012 07:43 PM, Mario Torre wrote:
>>
>> 2012/4/23 Rémi Forax<fo...@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.MAX_VALUE
> h = Math.min(i, Integer.MAX_VALUE - (-low));
> }
> high = h;
>
> ...
> }
>
> cheers,
> Rémi
>
