Review request: Clean up BarrierSet contructors and destructors
jon.masamitsu at oracle.com
Mon Jan 26 19:19:23 UTC 2015
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
> Part of the point of the enhancement request was to eliminate all the brief assignments
> that are quickly overwritten by derived classes.
More information about the hotspot-gc-dev