RFR(s): 8068582: UseSerialGC not always set up properly

Per Liden per.liden at oracle.com
Mon Apr 20 18:43:02 UTC 2015


Hi Jon,

> On 20 Apr 2015, at 20:15, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
> 
> Per,
> 
> In place of
> 
> It is not possible to combine the ParNew young collector with anything other than the CMS collector
> 
> let me suggest
> 
> It is not possible to combine the ParNew young collector with any collector other than CMS

Yep, that sounds better. Will fix.

> 
> Otherwise, still looks good.

Thanks Jon!

/Per

> 
> Jon
> 
> On 04/20/2015 01:28 AM, Per Liden wrote:
>> Hi Bengt, 
>> 
>> On 2015-04-20 09:45, Bengt Rutisson wrote: 
>>> 
>>> Hi Per, 
>>> 
>>> On 2015-04-17 16:05, Per Liden wrote: 
>>>> Hi, 
>>>> 
>>>> When no Use*GC flag is specified on the command-line we make a default 
>>>> GC selection. In case we select SerialGC we fail to set UseSerialGC to 
>>>> true (unlike when we select ParallelGC where we set UseParallelGC). 
>>>> This means we can run with all Use*GC set to false (which implicitly 
>>>> means we're using serial). It also means we can't use UseSerialGC as 
>>>> the sole indicator that we're using serial. 
>>>> 
>>>> This patch makes sure that we always set the corresponding Use*GC for 
>>>> the GC we have selected. 
>>>> 
>>>> A typical case where the VM selects serial but fails to set 
>>>> UseSerialGC is when running a client VM without specifying a Use*GC 
>>>> option on the command-line. 
>>>> 
>>>> Testing: Added a new jtreg test, passes jprt 
>>>> 
>>>> Webrev: http://cr.openjdk.java.net/~pliden/8068582/webrev.0/ <http://cr.openjdk.java.net/~pliden/8068582/webrev.0/> 
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8068582 <https://bugs.openjdk.java.net/browse/JDK-8068582> 
>>> 
>>> The changes look good, but there are a couple of comments in the code 
>>> that would be nice to clean up now that you enforce that UseSerialGC is 
>>> properly set  up: 
>>> 
>>> genCollectedHeap.hpp: 
>>> 
>>>    virtual bool can_elide_initializing_store_barrier(oop new_obj) { 
>>>      // We wanted to assert that:- 
>>>      // assert(UseSerialGC || UseConcMarkSweepGC, 
>>>      //       "Check can_elide_initializing_store_barrier() for this 
>>> collector"); 
>>>      // but unfortunately the flag UseSerialGC need not necessarily always 
>>>      // be set when DefNew+Tenured are being used. 
>>>      return is_in_young(new_obj); 
>>>    } 
>>> 
>>> 
>>> arguments.cpp: 
>>> 
>>>    if (UseParNewGC && !UseConcMarkSweepGC) { 
>>>      // !UseConcMarkSweepGC means that we are using serial old gc. 
>>> Unfortunately we don't 
>>>      // set up UseSerialGC properly, so that can't be used in the check 
>>> here. 
>>>      jio_fprintf(defaultStream::error_stream(), 
>>>          "It is not possible to combine the ParNew young collector with 
>>> the Serial old collector.\n"); 
>>>      return false; 
>>>    } 
>>> 
>>> 
>>> In both these cases I think we can just remove the comments. The 
>>> suggested assert in can_elide_initializing_store_barrier() is not 
>>> interesting to add in my opinion since it is code in GenCollectedHeap, 
>>> which we know is only used by Serial and CMS. 
>> 
>> Good catch. I will remove both of these. 
>> 
>> I'll also adjust the error message there from: 
>> 
>>  "It is not possible to combine the ParNew young collector with the Serial old collector. 
>> 
>> to: 
>> 
>> "It is not possible to combine the ParNew young collector with anything other than the CMS collector." 
>> 
>> Because it doesn't makes sense to mention SerialOld when you say e.g. -XX:+UseParNewGC -XX:+UseParallelOldGC 
>> 
>> Here's an updated webrev: 
>> http://cr.openjdk.java.net/~pliden/8068582/webrev.1/ <http://cr.openjdk.java.net/~pliden/8068582/webrev.1/> 
>> 
>> Diff against previous webrev: 
>> http://cr.openjdk.java.net/~pliden/8068582/webrev.1-diff/ <http://cr.openjdk.java.net/~pliden/8068582/webrev.1-diff/> 
>> 
>> Thanks for reviewing! 
>> 
>> /Per 
>> 
>>> 
>>> Thanks, 
>>> Bengt 
>>> 
>>>> 
>>>> /Per 
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150420/9aba6b5a/attachment.htm>


More information about the hotspot-gc-dev mailing list