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

[Nils Eliasson]

Some new updates:

- Atomic::writes replaces the sweeper statistics lock.

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

Thanks,
Nils

On 2013-06-18 17:21, Vladimir Kozlov wrote:
> Yes, I think it is acceptable now. I will ask Christian to look on this.
>
> Thanks,
> Vladimir
>
> On 6/18/13 7:15 AM, Nils Eliasson wrote:
>> 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/20130621/d446ef04/attachment.html