RFR: 8224162: assert(profile.count() == 0) failed: sanity in InlineTree::is_not_reached

[Vladimir Ivanov]

Hi Jie,

The failure is caused by saturated_add() returning 0 for non-zero 
arguments on sparc. The culprit is jlong vs jint and 
reinterpret_cast<int&>. I believe what happens is, since sparc is 
big-endian, the cast from 64-bit to 32-bit may return upper part of the 
value (depending on actual machine code). I suggest to fix it by 
switching from reinterpret_cast to static_cast.

Along with the fix, I slightly refactored your patch and ended up with 
the following version:
   http://cr.openjdk.java.net/~vlivanov/jiefu/8224162/webrev.11_10/

Let me know what you think about it.

Best regards,
Vladimir Ivanov

On 03/06/2019 16:55, Vladimir Ivanov wrote:
> FYI there was a new failure in compiler/unsafe/UnsafeGetConstantField 
> spotted on solaris-sparcv9.  I'm looking into it and let you know about 
> my findings.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 01/06/2019 04:37, Jie Fu wrote:
>> Hi Vladimir Ivanov,
>>
>> Thanks for your review and suggestions.
>> Updated: http://cr.openjdk.java.net/~jiefu/8224162/webrev.10/
>>
>> Thanks a lot.
>> Best regards,
>> Jie
>>
>> On 2019/6/1 上午5:47, Vladimir Ivanov wrote:
>>> +template <typename L, typename R>
>>> +int ciMethod::saturated_add(L a, R b) {
>>>
>>> What do you think about moving it to globalDefinitions.hpp?
>>>
>>> Probably, it's worth getting rid of the template parameters and 
>>> introduce specializations (akin to JAVA_INTEGER_OP) since the 
>>> implementation makes sense only for int/uint.
>> It seems cool. I like this style.
>>>
>>> +  jlong sum  = src1 + src2;
>>> I'd prefer to see explicit casts to jlong to stress there's no 
>>> overflow possible here for 32-bit values.
>>>
>> Done
>>>
>>> +    return c < 0 ? max_jint : c;
>>> +      case Bytecodes::_instanceof: return c > 0 ? min_jint : c;
>>>
>>> Please, put parentheses around ternary expressions.
>>>
>> Done
>>
>>