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

Jie Fu fujie at loongson.cn
Fri May 31 05:03:04 UTC 2019

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.

   make test TEST="tier1 tier2 tier3" JTREG="JOBS=4" CONF=release on 

Thanks a lot.
Best regards,


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

> 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).


> 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

More information about the hotspot-compiler-dev mailing list