Stability of UseCodeCacheFlushing option

[John O'Brien]

Hi All,

Is the useCodeCacheFlushing option working well. I read the thread
below and wonder if there are remaining issues?
How bad are they? Do I just need to go ahead and try it out?

Is the best option to size a very large codeCache?

Regards,
John




Tom Rodriguez tom.rodriguez at oracle.com
Thu Mar 3 12:14:32 PST 2011

Previous message: inspecting the code cache
Next message: Request for review(M): 7020403: Add
AdvancedCompilationPolicy for tiered
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

________________________________

>>> 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
>
>
>