RFR(M): 8008287: Code cache statistic variables for event tracing needs atomicity

[Nils Eliasson]

I have minimized the critical zones, moving max out. Also guarding all 
calls to os::elapsed_counter() with Tracing::enabled() and 
INCLUDE_TRACE. Had to reintroduce a duplication of timers in sweeper for 
some PrintMethodFlushing statistics behind ifdef ASSERT. Not super 
pretty or compact, but at least straightforward and easy to read.

http://cr.openjdk.java.net/~neliasso/8008287/webrev.06/ 
<http://cr.openjdk.java.net/%7Eneliasso/8008287/webrev.06/>

//Nils Eliasson

On 2013-06-17 01:06, Vladimir Kozlov wrote:
> Nils,
>
> NMethodSweeper::speculative_disconnect_nmethods() is called during 
> safepoint (VM operation) so lock in it will affect safepoint time. But 
> I don't know how to avoid the lock here except use it only when atomic 
> long store is not available. One thing you can do to shorten time in 
> lock is to move the addition and MAX2 operations outside the lock 
> (leave only stores inside) since it is the only place where these 
> values are modified.
>
> +  {
> +    MutexLockerEx ml(CodeSweeperStatistics_lock);
>    _total_disconnect_time += disconnect_time;
>    _peak_disconnect_time = MAX2(disconnect_time, _peak_disconnect_time);
> +  }
>
> thanks,
> Vladimir
>
> On 6/16/13 3:00 PM, Nils Eliasson wrote:
>> Updated,
>>
>> Unnecessary lock removed from scan_stacks.
>>
>> http://cr.openjdk.java.net/~neliasso/8008287/webrev.05
>>
>> //Nils Eliasson
>>
>> On 2013-04-30 17:27, Nils Eliasson wrote:
>>> Hi,
>>>
>>> I have fixed some atomicity issues for the sweeper tracing and did 
>>> some refactoring at the same time, removing
>>> duplicate counters.
>>>
>>> I guess people might have opinions on this, but I have chosen to 
>>> only use the perf_counters when available instead of
>>> always having a normal counter and an additional perf_counter in 
>>> specific scenarios.
>>>
>>> Also changed the type of the traversal counter (and the 
>>> stack_traversal marker in nmethod). It should be good for 126
>>> years of sweeping once a second anyway (and we don't complete full 
>>> sweeps that often.)
>>>
>>> http://bugs.sun.com/view_bug.do?bug_id=8008287
>>> https://jbs.oracle.com/bugs/browse/JDK-8008287
>>> http://cr.openjdk.java.net/~neliasso/8008287/webrev.04 
>>> <http://cr.openjdk.java.net/%7Eneliasso/8008287/webrev.04>
>>>
>>> Thanks,
>>> Nils Eliasson
>>>
>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20130618/3e717261/attachment-0001.html