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

[Nils Eliasson]

Since Wednesday we need approval to push (rampdown phase 2, June 19). 
When I started working on this the events weren't in 8/hsx25.

//N

On 2013-06-22 00:20, Vladimir Kozlov wrote:
> Nils,
>
> Why it is based on hsx24 sources? It should be pushed first into hs25 
> and tested there. For hs24 we would need approval to push.
>
> Changes are good.
>
> Thanks,
> Vladimir
>
> On 6/21/13 2:16 PM, Nils Eliasson wrote:
>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>