inspecting the code cache

[Tom Rodriguez]

>>> Thanks for that information. I've been using PrintCompilation to
>> watch what was going on. I've gotten a question from a client that
>> claims that a method had seemingly been squeezed out of the cache. I'm
>> not sure what would cause a method to be squeezed out but I guess it
>> would have to be made not entrant before hand. But that got me
>> interested in poking about to see what information one could squeeze
>> out of the JVM wrt the code cache.
>> 
>> Code will never get "squeezed" out in the current system.  We generate
>> code as needed and only get rid of it when it gets invalidated or if it
>> references classes which get unloaded.  If the code cache fills up you
>> might not be able to compile something that needs code though.
>> 
>> tom
>> 
>> 
>>> 
>>> TIA,
>>> Kirk
>>> 
> 
> Does -XX:+UseCodeCacheFlushing enable this clearing of invalidated code? 
> Or does that do something different?

No that's something different.  The clearing of the code is done by something called the sweeper and you can't disable it.  UseCodeCacheFlushing implements an LRU-ish policy for keeping the code cache from filling up.  It's currently not enabled by default because we've seen some hard to track down problems when using it with very long running programs.  They may not actually be the fault of the flushing itself but the extra pressure it puts on the concurrent sweeping that actually reclaims them.  It should become the default once we track down the sweeping issue.

tom

> 
> 
> Thanks,
> 
> David
> 
> 
>