Review request: Clean up BarrierSet contructors and destructors
jon.masamitsu at oracle.com
Mon Jan 26 19:30:09 UTC 2015
On 01/26/2015 11:19 AM, Jon Masamitsu wrote:
> Reposting since I should have replied to the list.
> On 01/26/2015 11:13 AM, Kim Barrett wrote:
>> On Jan 26, 2015, at 1:50 PM, Jon Masamitsu <jon.masamitsu at oracle.com>
>>> On 01/26/2015 10:25 AM, joe provino wrote:
>>>> Hi Jon, thanks for taking a look at this.
>>>> It seems there is a potential to pass in the wrong kind.
>>>> Is there a way to prevent that?
>>> Can you only remove Uninit and the initialization of
>>> _kind in the BarrierSet constructor? And let the
>>> subclasses continue to set their kinds?
>> This discussion probably ought to be in the open, not private between
>> The non-concrete subclasses presently set _kind and then have that
>> almost immediately written over by a further derived subclass. The
>> only exception
>> to this is CardTableModRefBS, whose two subclasses don’t set _kind.
>> But that’s
>> very likely a bug of a different sort, in that CardTableExtension
>> never assigns _kind
>> to BarrierSet::CardTableExtension - that BarrierSet::Name is never
>> assigned at
>> Part of the point of the enhancement request was to eliminate all the
>> brief assignments
>> that are quickly overwritten by derived classes.
Okay, but passing the "kind" to the constructor of a class that should
only be of that "kind" seems odd, no?
More information about the hotspot-gc-dev