Support large codecache for JDK8
Attached for review is a patch which adds large codecache support to jdk8 (jdk7 version will be next). It passes basic smoke tests (java hello, javac Hello.java, netbeans build and run simple project). Ok to push? regards, Andrew Dinn -----------
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? Andrew.
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? regards, Andrew Dinn -----------
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.
On 10/03/15 14:30, Andrew Haley wrote:
On 03/10/2015 12:08 PM, Andrew Dinn wrote:
. . . 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...
Hmm, well, since we own the jdk8 tree I can push and then we can try it :-)
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.
I have run netbeans with a slowdebug build, using it to rebuild and run a sample project. Apart from being slow as treacle it ran fine. regards, Andrew Dinn -----------
Hi Andrew, Did this patch ever make it into jdk8 (and/or jdk7)? One of our partners has reported problems with the Apace BigTop build which uses JDK 7 and sets -XX:ReservedCodeCacheSize=512M. The problem seems to be a BL going out of range. All the best, Ed. On Tue, 2015-03-10 at 10:28 +0000, Andrew Dinn wrote:
Attached for review is a patch which adds large codecache support to jdk8 (jdk7 version will be next).
It passes basic smoke tests (java hello, javac Hello.java, netbeans build and run simple project).
Ok to push?
regards,
Andrew Dinn -----------
# HG changeset patch # User adinn # Date 1425980888 0 # Tue Mar 10 09:48:08 2015 +0000 # Node ID 2486a66bb7e7b7e013050fbf8b2924b8149ebaad # Parent a747c1771e54e289f478387bd74ae34660f388ee Support for large code caches
On 25/11/15 10:22, Edward Nevill wrote:
Did this patch ever make it into jdk8 (and/or jdk7)? One of our partners has reported problems with the Apace BigTop build which uses JDK 7 and sets -XX:ReservedCodeCacheSize=512M. The problem seems to be a BL going out of range.
No, it's not in. I think it got left pending because of other things that were going on and then was forgotten about. I guess we ought to rework it (assuming it needs work to cater for changes in the interim) and push to 8 and then also backport it to 7. regards, Andrew Dinn
On 11/25/2015 12:50 PM, Andrew Dinn wrote:
On 25/11/15 10:22, Edward Nevill wrote:
Did this patch ever make it into jdk8 (and/or jdk7)? One of our partners has reported problems with the Apace BigTop build which uses JDK 7 and sets -XX:ReservedCodeCacheSize=512M. The problem seems to be a BL going out of range.
No, it's not in. I think it got left pending because of other things that were going on and then was forgotten about. I guess we ought to rework it (assuming it needs work to cater for changes in the interim) and push to 8 and then also backport it to 7.
I think this patch is very nearly a clone of http://hg.openjdk.java.net/aarch64-port/jdk9/hotspot/rev/5a92ef3b79a5 The main difference is, I think, the setting of CODE_CACHE_SIZE_LIMIT. I am very keen not to see divergence in this area if at all possible, so this looks okay. I don't think it's been changed much. Ed, does the Apace BigTop build suffer with default ReservedCodeCacheSize? I'vebeen wanting to find out if a larger code cache outweighs the overhead of trampolines. Andrew.
participants (3)
-
Andrew Dinn
-
Andrew Haley
-
Edward Nevill