Request for review (S): 8003820: Deprecate untested and rarely used GC combinations
Hi all, Can I have a couple of reviews for this change to deprecate the DefNew + CMS and ParNew + SerialOld GC combinations? http://cr.openjdk.java.net/~brutisso/8003820/webrev.00/ This is part of the work for JEP 173: JEP 173: Retire Some Rarely-Used GC Combinations http://openjdk.java.net/jeps/173 The work is tracked in this bug: 8003820 : Deprecate untested and rarely used GC combinations http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003820 Thanks, Bengt
Ship it! /Jesper On 2012-12-18 15:02, Bengt Rutisson wrote:
Hi all,
Can I have a couple of reviews for this change to deprecate the DefNew + CMS and ParNew + SerialOld GC combinations?
http://cr.openjdk.java.net/~brutisso/8003820/webrev.00/
This is part of the work for JEP 173:
JEP 173: Retire Some Rarely-Used GC Combinations http://openjdk.java.net/jeps/173
The work is tracked in this bug:
8003820 : Deprecate untested and rarely used GC combinations http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003820
Thanks, Bengt
Hi Bengt -- Looks fine (although -- and this not part of the CR -- Arguments::parse() seems to have grown rather large and wants to be refactored into a few distinct pieces -- perhaps by "functional module"; but that's another bug). What happens when you run CMS on a single-processor. I hope you don't see a deprecation warning. -- ramki On Tue, Dec 18, 2012 at 6:02 AM, Bengt Rutisson <bengt.rutisson@oracle.com>wrote:
Hi all,
Can I have a couple of reviews for this change to deprecate the DefNew + CMS and ParNew + SerialOld GC combinations?
http://cr.openjdk.java.net/~brutisso/8003820/webrev.00/
This is part of the work for JEP 173:
JEP 173: Retire Some Rarely-Used GC Combinations http://openjdk.java.net/jeps/173
The work is tracked in this bug:
8003820 : Deprecate untested and rarely used GC combinations http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003820
Thanks, Bengt
Also, to a point that Peter Kessler made earlier. What is the performance hit when you run ParNew with #gc threads = 1, versus DefNew (with CMS in old gen of course) ? It would be good to measure and know, even if we are ready to swallow that hit for practical reasons. -- ramki On Wed, Dec 19, 2012 at 4:59 PM, Srinivas Ramakrishna <ysr1729@gmail.com>wrote:
Hi Bengt --
Looks fine (although -- and this not part of the CR -- Arguments::parse() seems to have grown rather large and wants to be refactored into a few distinct pieces -- perhaps by "functional module"; but that's another bug).
What happens when you run CMS on a single-processor. I hope you don't see a deprecation warning.
-- ramki
On Tue, Dec 18, 2012 at 6:02 AM, Bengt Rutisson <bengt.rutisson@oracle.com
wrote:
Hi all,
Can I have a couple of reviews for this change to deprecate the DefNew + CMS and ParNew + SerialOld GC combinations?
http://cr.openjdk.java.net/~brutisso/8003820/webrev.00/
This is part of the work for JEP 173:
JEP 173: Retire Some Rarely-Used GC Combinations http://openjdk.java.net/jeps/173
The work is tracked in this bug:
8003820 : Deprecate untested and rarely used GC combinations http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003820
Thanks, Bengt
Hi Ramki, Thanks for looking at this! On 12/20/12 1:59 AM, Srinivas Ramakrishna wrote:
Hi Bengt --
Looks fine (although -- and this not part of the CR -- Arguments::parse() seems to have grown rather large and wants to be refactored into a few distinct pieces -- perhaps by "functional module"; but that's another bug).
You are absolutely right. We need to clean Arguments::parse() up, but we should not do it as part of this fix. :)
What happens when you run CMS on a single-processor. I hope you don't see a deprecation warning.
Ooops. Good point. It took me a long while to find a machine with just one cpu that could actually run JDK8. But you are correct. We will print a warning in that case. I think the fix is to not pick DefNew by default for single processor machines. I'll see if I can get any performance data for that. Thanks, Bengt
-- ramki
On Tue, Dec 18, 2012 at 6:02 AM, Bengt Rutisson <bengt.rutisson@oracle.com <mailto:bengt.rutisson@oracle.com>> wrote:
Hi all,
Can I have a couple of reviews for this change to deprecate the DefNew + CMS and ParNew + SerialOld GC combinations?
http://cr.openjdk.java.net/~brutisso/8003820/webrev.00/ <http://cr.openjdk.java.net/%7Ebrutisso/8003820/webrev.00/>
This is part of the work for JEP 173:
JEP 173: Retire Some Rarely-Used GC Combinations http://openjdk.java.net/jeps/173
The work is tracked in this bug:
8003820 : Deprecate untested and rarely used GC combinations http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8003820
Thanks, Bengt
What happens when you run CMS on a single-processor. I hope you don't see a
deprecation warning.
Ooops. Good point. It took me a long while to find a machine with just one cpu that could actually run JDK8. But you are correct. We will print a warning in that case.
Remember that virtualized platforms or LDOMS or Zones may partition a large box into small 1-cpu slices (although may be not 1-core). On Solaris, you can easily test your code by means of psradm to turn off all but one virtual cpu.
I think the fix is to not pick DefNew by default for single processor machines. I'll see if I can get any performance data for that.
I'd test that on a regular MP with ParNew=1 vs DefNew, as well as separately with psrset and pbind (although my guess is that the latter two would be indistinguishable from each other). As I recall, scaling was near linear at those small numbers for ParNew, and the breakeven point was at 2, so my guess based on very old data from the fogs of time is that we'd see a fairly sizable pause time and overhead hit on a single cpu. Stepping back for a moment, is supporting embedded environments perhaps from the same parent code base an issue, so DefNew & Serial is going to be part of the code base for a while, anyway? I understand though that saving on testing resources by pruning down supported combinations is one important motivation, in which case DefNew+CMS gets deprecated (and switches to Parnew/1+CMS on 1-cpu configs), but DefNew continues to be part of the code base, and so DefNew code gets used (and tested) at least in part to the extent that ParNew uses at least some functionality defined in DefNew. -- ramki
Hi Ramki, On 12/20/12 9:21 PM, Srinivas Ramakrishna wrote:
What happens when you run CMS on a single-processor. I hope you don't see a deprecation warning.
Ooops. Good point. It took me a long while to find a machine with just one cpu that could actually run JDK8. But you are correct. We will print a warning in that case.
Remember that virtualized platforms or LDOMS or Zones may partition a large box into small 1-cpu slices (although may be not 1-core).
Right. That is actually what I ended up doing. Running Ubuntu in a VirtualBox set up to use one CPU.
On Solaris, you can easily test your code by means of psradm to turn off all but one virtual cpu.
I think the fix is to not pick DefNew by default for single processor machines. I'll see if I can get any performance data for that.
I'd test that on a regular MP with ParNew=1 vs DefNew, as well as separately with psrset and pbind (although my guess is that the latter two would be indistinguishable from each other). As I recall, scaling was near linear at those small numbers for ParNew, and the breakeven point was at 2, so my guess based on very old data from the fogs of time is that we'd see a fairly sizable pause time and overhead hit on a single cpu.
I did one set of test runs with SpecJBB2005 on the single CPU VirtualBox instance that I have. I got these scores: 17691 DefNew 17778 ParNew ParallelGCThreads=0 17770 ParNew ParallelGCThreads=1 I will do more runs and I'll also try it on a MT system as you suggested. But primarily the results look good.
Stepping back for a moment, is supporting embedded environments perhaps from the same parent code base an issue, so DefNew & Serial is going to be part of the code base for a while, anyway?
I understand though that saving on testing resources by pruning down supported combinations is one important motivation, in which case DefNew+CMS gets deprecated (and switches to Parnew/1+CMS on 1-cpu configs), but DefNew continues to be part of the code base, and so DefNew code gets used (and tested) at least in part to the extent that ParNew uses at least some functionality defined in DefNew.
Absolutely correct. We will keep the DefNew + SerialOld combo. We just want to cut down on the permutations that we need to test and support. So we aim to deprecate DefNew + CMS. But we will keep DefNew and still support and test it in combination with SerialOld. Bengt
-- ramki
Hi Ramki, I made the change to pick ParNew by default also on single CPU systems. However, I think this change deserves a separate bug ID and changeset. So, I just sent out a new review request with just this change. Once that has been handled. I think the review request discussed in this email thread will look exactly as it is now. Thanks again for looking at this! Bengt On 12/20/12 9:21 PM, Srinivas Ramakrishna wrote:
What happens when you run CMS on a single-processor. I hope you don't see a deprecation warning.
Ooops. Good point. It took me a long while to find a machine with just one cpu that could actually run JDK8. But you are correct. We will print a warning in that case.
Remember that virtualized platforms or LDOMS or Zones may partition a large box into small 1-cpu slices (although may be not 1-core).
On Solaris, you can easily test your code by means of psradm to turn off all but one virtual cpu.
I think the fix is to not pick DefNew by default for single processor machines. I'll see if I can get any performance data for that.
I'd test that on a regular MP with ParNew=1 vs DefNew, as well as separately with psrset and pbind (although my guess is that the latter two would be indistinguishable from each other). As I recall, scaling was near linear at those small numbers for ParNew, and the breakeven point was at 2, so my guess based on very old data from the fogs of time is that we'd see a fairly sizable pause time and overhead hit on a single cpu.
Stepping back for a moment, is supporting embedded environments perhaps from the same parent code base an issue, so DefNew & Serial is going to be part of the code base for a while, anyway?
I understand though that saving on testing resources by pruning down supported combinations is one important motivation, in which case DefNew+CMS gets deprecated (and switches to Parnew/1+CMS on 1-cpu configs), but DefNew continues to be part of the code base, and so DefNew code gets used (and tested) at least in part to the extent that ParNew uses at least some functionality defined in DefNew.
-- ramki
Bengt Rutisson (bengt.rutisson@oracle.com) wrote:
Hi Ramki,
I made the change to pick ParNew by default also on single CPU systems. However, I think this change deserves a separate bug ID and changeset. So, I just sent out a new review request with just this change.
Once that has been handled. I think the review request discussed in this email thread will look exactly as it is now.
Given the other change to keep ParNew enabled on 1-cpu systems, this looks good to me. You might want to append to the warning something along the lines of "and will likely be removed in a future release". We intend to remove this, so "deprecated" here is notably different from its use in the Java APIs, where nothing deprecated has ever been removed. -John
Thanks again for looking at this! Bengt
On 12/20/12 9:21 PM, Srinivas Ramakrishna wrote:
What happens when you run CMS on a single-processor. I hope you don't see a deprecation warning.
Ooops. Good point. It took me a long while to find a machine with just one cpu that could actually run JDK8. But you are correct. We will print a warning in that case.
Remember that virtualized platforms or LDOMS or Zones may partition a large box into small 1-cpu slices (although may be not 1-core).
On Solaris, you can easily test your code by means of psradm to turn off all but one virtual cpu.
I think the fix is to not pick DefNew by default for single processor machines. I'll see if I can get any performance data for that.
I'd test that on a regular MP with ParNew=1 vs DefNew, as well as separately with psrset and pbind (although my guess is that the latter two would be indistinguishable from each other). As I recall, scaling was near linear at those small numbers for ParNew, and the breakeven point was at 2, so my guess based on very old data from the fogs of time is that we'd see a fairly sizable pause time and overhead hit on a single cpu.
Stepping back for a moment, is supporting embedded environments perhaps from the same parent code base an issue, so DefNew & Serial is going to be part of the code base for a while, anyway?
I understand though that saving on testing resources by pruning down supported combinations is one important motivation, in which case DefNew+CMS gets deprecated (and switches to Parnew/1+CMS on 1-cpu configs), but DefNew continues to be part of the code base, and so DefNew code gets used (and tested) at least in part to the extent that ParNew uses at least some functionality defined in DefNew.
-- ramki
Hi John, Thanks for looking at this! On 12/22/12 1:38 AM, John Coomes wrote:
Bengt Rutisson (bengt.rutisson@oracle.com) wrote:
Hi Ramki,
I made the change to pick ParNew by default also on single CPU systems. However, I think this change deserves a separate bug ID and changeset. So, I just sent out a new review request with just this change.
Once that has been handled. I think the review request discussed in this email thread will look exactly as it is now. Given the other change to keep ParNew enabled on 1-cpu systems, this looks good to me.
You might want to append to the warning something along the lines of "and will likely be removed in a future release". We intend to remove this, so "deprecated" here is notably different from its use in the Java APIs, where nothing deprecated has ever been removed.
Good point. Updated webrev: http://cr.openjdk.java.net/~brutisso/8003820/webrev.01/ Thanks, Bengt
-John
Thanks again for looking at this! Bengt
On 12/20/12 9:21 PM, Srinivas Ramakrishna wrote:
What happens when you run CMS on a single-processor. I hope you don't see a deprecation warning.
Ooops. Good point. It took me a long while to find a machine with just one cpu that could actually run JDK8. But you are correct. We will print a warning in that case.
Remember that virtualized platforms or LDOMS or Zones may partition a large box into small 1-cpu slices (although may be not 1-core).
On Solaris, you can easily test your code by means of psradm to turn off all but one virtual cpu.
I think the fix is to not pick DefNew by default for single processor machines. I'll see if I can get any performance data for that.
I'd test that on a regular MP with ParNew=1 vs DefNew, as well as separately with psrset and pbind (although my guess is that the latter two would be indistinguishable from each other). As I recall, scaling was near linear at those small numbers for ParNew, and the breakeven point was at 2, so my guess based on very old data from the fogs of time is that we'd see a fairly sizable pause time and overhead hit on a single cpu.
Stepping back for a moment, is supporting embedded environments perhaps from the same parent code base an issue, so DefNew & Serial is going to be part of the code base for a while, anyway?
I understand though that saving on testing resources by pruning down supported combinations is one important motivation, in which case DefNew+CMS gets deprecated (and switches to Parnew/1+CMS on 1-cpu configs), but DefNew continues to be part of the code base, and so DefNew code gets used (and tested) at least in part to the extent that ParNew uses at least some functionality defined in DefNew.
-- ramki
Thanks Ramki, John and Jesper for the reviews! Pushing this now. Bengt On 12/22/12 6:08 AM, Bengt Rutisson wrote:
Hi John,
Thanks for looking at this!
On 12/22/12 1:38 AM, John Coomes wrote:
Bengt Rutisson (bengt.rutisson@oracle.com) wrote:
Hi Ramki,
I made the change to pick ParNew by default also on single CPU systems. However, I think this change deserves a separate bug ID and changeset. So, I just sent out a new review request with just this change.
Once that has been handled. I think the review request discussed in this email thread will look exactly as it is now. Given the other change to keep ParNew enabled on 1-cpu systems, this looks good to me.
You might want to append to the warning something along the lines of "and will likely be removed in a future release". We intend to remove this, so "deprecated" here is notably different from its use in the Java APIs, where nothing deprecated has ever been removed.
Good point. Updated webrev:
http://cr.openjdk.java.net/~brutisso/8003820/webrev.01/
Thanks, Bengt
-John
Thanks again for looking at this! Bengt
On 12/20/12 9:21 PM, Srinivas Ramakrishna wrote:
What happens when you run CMS on a single-processor. I hope you don't see a deprecation warning.
Ooops. Good point. It took me a long while to find a machine with just one cpu that could actually run JDK8. But you are correct. We will print a warning in that case.
Remember that virtualized platforms or LDOMS or Zones may partition a large box into small 1-cpu slices (although may be not 1-core).
On Solaris, you can easily test your code by means of psradm to turn off all but one virtual cpu.
I think the fix is to not pick DefNew by default for single processor machines. I'll see if I can get any performance data for that.
I'd test that on a regular MP with ParNew=1 vs DefNew, as well as separately with psrset and pbind (although my guess is that the latter two would be indistinguishable from each other). As I recall, scaling was near linear at those small numbers for ParNew, and the breakeven point was at 2, so my guess based on very old data from the fogs of time is that we'd see a fairly sizable pause time and overhead hit on a single cpu.
Stepping back for a moment, is supporting embedded environments perhaps from the same parent code base an issue, so DefNew & Serial is going to be part of the code base for a while, anyway?
I understand though that saving on testing resources by pruning down supported combinations is one important motivation, in which case DefNew+CMS gets deprecated (and switches to Parnew/1+CMS on 1-cpu configs), but DefNew continues to be part of the code base, and so DefNew code gets used (and tested) at least in part to the extent that ParNew uses at least some functionality defined in DefNew.
-- ramki
Sorry for the delay in responding. The changes (this and the other bug id for ParNew/1) all look good; thanks for verifying the performance numbers as well! thanks! -- ramki On Fri, Jan 4, 2013 at 2:23 AM, Bengt Rutisson <bengt.rutisson@oracle.com>wrote:
Thanks Ramki, John and Jesper for the reviews!
Pushing this now.
Bengt
On 12/22/12 6:08 AM, Bengt Rutisson wrote:
Hi John,
Thanks for looking at this!
On 12/22/12 1:38 AM, John Coomes wrote:
Bengt Rutisson (bengt.rutisson@oracle.com) wrote:
Hi Ramki,
I made the change to pick ParNew by default also on single CPU systems. However, I think this change deserves a separate bug ID and changeset. So, I just sent out a new review request with just this change.
Once that has been handled. I think the review request discussed in this email thread will look exactly as it is now.
Given the other change to keep ParNew enabled on 1-cpu systems, this looks good to me.
You might want to append to the warning something along the lines of "and will likely be removed in a future release". We intend to remove this, so "deprecated" here is notably different from its use in the Java APIs, where nothing deprecated has ever been removed.
Good point. Updated webrev:
Thanks, Bengt
-John
Thanks again for looking at this!
Bengt
On 12/20/12 9:21 PM, Srinivas Ramakrishna wrote:
What happens when you run CMS on a single-processor. I hope you
don't see a deprecation warning.
Ooops. Good point. It took me a long while to find a machine with just one cpu that could actually run JDK8. But you are correct. We will print a warning in that case.
Remember that virtualized platforms or LDOMS or Zones may partition a large box into small 1-cpu slices (although may be not 1-core).
On Solaris, you can easily test your code by means of psradm to turn off all but one virtual cpu.
I think the fix is to not pick DefNew by default for single processor machines. I'll see if I can get any performance data for that.
I'd test that on a regular MP with ParNew=1 vs DefNew, as well as separately with psrset and pbind (although my guess is that the latter two would be indistinguishable from each other). As I recall, scaling was near linear at those small numbers for ParNew, and the breakeven point was at 2, so my guess based on very old data from the fogs of time is that we'd see a fairly sizable pause time and overhead hit on a single cpu.
Stepping back for a moment, is supporting embedded environments perhaps from the same parent code base an issue, so DefNew & Serial is going to be part of the code base for a while, anyway?
I understand though that saving on testing resources by pruning down supported combinations is one important motivation, in which case DefNew+CMS gets deprecated (and switches to Parnew/1+CMS on 1-cpu configs), but DefNew continues to be part of the code base, and so DefNew code gets used (and tested) at least in part to the extent that ParNew uses at least some functionality defined in DefNew.
-- ramki
participants (4)
-
Bengt Rutisson
-
Jesper Wilhelmsson
-
John Coomes
-
Srinivas Ramakrishna