On 03/10/2015 12:08 PM, Andrew Dinn wrote:
On 10/03/15 10:53, Andrew Haley wrote:
On 03/10/2015 10:28 AM, Andrew Dinn wrote:
Ok to push?
It looks reasonable. Does the large code cache kick in with the default configuration? Do we want it to?
This is essentially the same patch as was applied to 9. So, the code cache size is driven by the value of ReservedCodeCache size.
That variable defaults to 48*M but with tiered it gets multiplied up to 5 times that i.e. 240*M and then rounded back down to 128*M by this code:
// Increase the code cache size - tiered compiles a lot more. if (FLAG_IS_DEFAULT(ReservedCodeCacheSize)) { FLAG_SET_ERGO(uintx, ReservedCodeCacheSize, MIN2(CODE_CACHE_DEFAULT_LIMIT, ReservedCodeCacheSize * 5)); }
... and, of course, 128*M is the threshold value above which far branches become necessary.
In other words the answer to your first question is no.
I don't know the answer to the second question. Anyone who wants a larger cache can select it by setting ReservedCodeCache. Is this in some way inadequate?
I dunno. That code didn't make it into the jdk9/dev tree upstream so we get 240*M. However, the trampolines bloat the code quite a lot so maybe if we turned that cache size down it'd work better. Answers on a postcard... By the way, have you tested that the trampolines ect. work OK on JDK8? With a debug build they should be used with code sizes more than 2*M. Andrew.