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

[Vladimir Kozlov]

Good.

Thanks,
Vladimir

On 1/4/13 12:12 PM, Alexander Harlap wrote:
> 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
>>>>>>>
>>>>>>
>>>>