RFR: 8005204: Provide more detailed output on CodeCache usage

[Chris Plummer]

On 1/3/13 8:52 PM, 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).

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/>
>
> Sponsoring Alexander Harlap for that submission
>