Fwd: RFR: 8005204: Provide more detailed output on CodeCache usage

[Alexander Harlap]

Sorry about that.

Next version is here: 
http://cr.openjdk.java.net/~vladidan/8005204/webrev.02/ 
<http://cr.openjdk.java.net/%7Evladidan/8005204/webrev.02/>

On 1/4/2013 2:23 PM, Vladimir Kozlov wrote:
> You forgot to pass 'detailed' parameter into print_summary() call. 
> Otherwise looks good.
>
> Vladimir
>
> On 1/4/13 10:55 AM, Alexander Harlap wrote:
>> New version of changeset uploaded to
>> http://cr.openjdk.java.net/~vladidan/8005204/webrev.01/
>> <http://cr.openjdk.java.net/%7Evladidan/8005204/webrev.01/>
>>
>> Alex
>>
>> On 1/4/2013 7:52 AM, Vladimir Danushevsky wrote:
>>> Alex, are you subscribed to this alias? Do you see the mails?
>>>
>>> Begin forwarded message:
>>>
>>>> *From: *Vladimir Kozlov <vladimir.kozlov at oracle.com
>>>> <mailto:vladimir.kozlov at oracle.com>>
>>>> *Date: *January 4, 2013 1:35:56 AM EST
>>>> *To: *hotspot-dev at openjdk.java.net 
>>>> <mailto:hotspot-dev at openjdk.java.net>
>>>> *Subject: **Re: RFR: 8005204: Provide more detailed output on
>>>> CodeCache usage*
>>>>
>>>> On 1/3/13 9:07 PM, Chris Plummer wrote:
>>>>> On 1/3/13 8:52 PM, hotspot-dev-request at openjdk.java.net
>>>>> <mailto:hotspot-dev-request at openjdk.java.net> wrote:
>>>>>> On 1/3/13 11:20 AM, Vitaly Davidovich wrote:
>>>>>>> >Vladimir,
>>>>>>> >
>>>>>>> >Unrelated to your change, but does
>>>>>>> CompileBroker::handle_full_code_cache()
>>>>>>> >need a ResourceMark since it calls stringStream::as_string()? 
>>>>>>> Or is
>>>>>>> the RM
>>>>>>> >created somewhere in the caller chain?
>>>>>> File separate bug. I found several places with similar usage of
>>>>>> stringStream::as_string() without ResourceMark.
>>>>>>
>>>>>> What I missed in my review for this changes is that
>>>>>> CompileBroker::handle_full_code_cache() does not obtain 
>>>>>> CodeCache_lock
>>>>>> before calling CodeCache::print_summary(tty) which I think we need
>>>>>> here.
>>>>>> Also it should be placed at the end of method after compilation is
>>>>>> switched off otherwise it will incorrectly print that compilation:
>>>>>> enabled.
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir
>>>>>>
>>>>> Regarding obtaining CodeCache_lock, is this also a pre-exiting 
>>>>> problem,
>>>>> or a new problem due to changes made in 
>>>>> CodeCache::print_summary(tty).
>>>>
>>>> Preexisting problem but it would be nice to fix it since we touching
>>>> this code.
>>>>
>>>> Vladimir
>>>>
>>>>>
>>>>> Chris
>>>>>
>>>>>> Code review for JDK-8005204 "Provide more detailed output on 
>>>>>> CodeCache
>>>>>> usage"
>>>>>>
>>>>>> We are adding more detailed output on CodeCache usage.
>>>>>>
>>>>>> Corresponding command line options are:
>>>>>>       -XX:+PrintCodeCache - Will print the size of the codecache 
>>>>>> at VM
>>>>>> exit. It will include the total size, used size, maximum used size,
>>>>>> maximum
>>>>>> free chunk, bounds, number of cached methods , etc.
>>>>>>      -XX:+**PrintCodeCacheOnCompilation - Same as PrintCodeCache, 
>>>>>> but
>>>>>> does
>>>>>> so each time a method is compiled. This is useful if the app does 
>>>>>> not
>>>>>> do a
>>>>>> normal JVM exit.
>>>>>>
>>>>>> Sample output:
>>>>>>
>>>>>> CodeCache: size=32768Kb used=542Kb max_used=542Kb free=32226Kb
>>>>>> max_free_chunk=32226Kb
>>>>>>    bounds [0xb414a000, 0xb41d2000, 0xb614a000]
>>>>>>    total_blobs=131 nmethods=5 adapters=63
>>>>>>    compilation: enabled
>>>>>>
>>>>>> Changeset:http://cr.openjdk.java.net/~**vladidan/8005204/webrev.00/<http://cr.openjdk.java.net/~vladidan/8005204/webrev.00/ 
>>>>>>
>>>>>> <http://cr.openjdk.java.net/%7Evladidan/8005204/webrev.00/>>
>>>>>>
>>>>>>
>>>>>> Sponsoring Alexander Harlap for that submission
>>>>>>
>>>>>
>>>