Review request: Clean up BarrierSet contructors and destructors

[Jon Masamitsu]

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> wrote:
>>
>> 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 us.
>
> The non-concrete subclasses presently set _kind and then have that assignment
> 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
> present.
>
> Part of the point of the enhancement request was to eliminate all the brief assignments
> that are quickly overwritten by derived classes.
>
>