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

[Jie Fu]

Hi Vladimir Ivanov,

Thank you for your review and guidance.
I benefit a lot from the discussion with you.
The patch had been updated based on your suggestions:
- http://cr.openjdk.java.net/~jiefu/8224162/webrev.07/

Also I had changed the parameter type of CounterData::set_count(...) 
from uint to int.
It is only used here[1], which I think is safe and clearer to do that.
Please review it and give me some advice.

Testing:
   make test TEST="tier1 tier2 tier3" JTREG="JOBS=4" CONF=release on 
Linux/x64

Thanks a lot.
Best regards,
Jie

[1] 
http://hg.openjdk.java.net/jdk/jdk/file/b0513c833960/src/hotspot/share/oops/methodData.hpp#l1170


On 2019/5/30 下午10:59, Vladimir Ivanov wrote:
> Switching return type to int would make it clearer.
>
Done


>
> call->receiver_count(i) is uint, so you still can experience overflow 
> when converting from uint to int. Considering receiver counts are 
> positive, I'd use saturating add on uints (and don't care about 
> min_jint).

Fixed.


> Regarding handling overflow during profiling:
>
>   * C1 doesn't handle counter overflow [1]
>
>   * What template interpreter does to avoid overflow is not enough for 
> concurrent case: it stores new value into memory and then 
> conditionally decrements it, but another thread may already see it. 
> Proper solution would be to keep the value in register, but that 
> requires a temporary register to burn.

Nice catch! I didn't realize the problem before. Thanks.


> So, it seems easier and cheaper (from the perspective of profiling 
> overhead) to handle that on compiler side when interpreting the data.
>
I agree.


>
> Best regards,
> Vladimir Ivanov
>
> [1] 
> http://hg.openjdk.java.net/jdk/jdk/file/c41783eb76eb/src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp#l1617