RFR (L): 8134994: use separate VMStructs databases for SA and JVMCI

[Christian Thalinger]

> On Dec 14, 2015, at 2:31 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> 
> On Dec 14, 2015, at 2:46 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>> 
>>> ------------------------------------------------------------------------------
>>> src/share/vm/gc/shared/cardTableModRefBS.hpp
>>> 43 class CardTableModRefBS: public ModRefBarrierSet {
>>> 44   // Some classes get to look at some private stuff.
>>> 45   friend class VMStructs;
>>> 46   friend class JVMCIVMStructs;
>>> 
>>> I thought we'd eliminated the need for this friendship for JVMCI too,
>>> though I'm less certain in this case.  Maybe its just been discussed
>>> how it could be done, but hasn't been done yet?
>> 
>> The friendship exists because of dirty_card which is protected but I can fix that with declare_constant_with_value.  I got rid of the friendship in G1SATBCardTableModRefBS also.
> 
> Thanks.  That looks good.
> 
>>> ------------------------------------------------------------------------------ 
>>> src/share/vm/jvmci/jvmciCompilerToVM.cpp
>>> 186     jbyte* base = ((CardTableModRefBS*)bs)->byte_map_base;
>>> 
>>> Use barrier_set_cast<CardTableModRefBS>(bs), so that when we refactor
>>> the barrier set hierarchy (which we plan to do), this will break in an
>>> obvious way.
>> 
>> Done.
>> 
>>> 
>>> And instead of the switch on bs->kind(), maybe use
>>> 
>>> if (bs->is_a(BarrierSet::CardTableModRefBS)) {
>>>   ... ;
>>> } else {
>>>   ShouldNotReachHere();
>>> }
>>> 
>>> All current implementations of BarrierSet are CTMRBS.  If/when that's
>>> no longer true, this will break in an obvious way.
>> 
>> What about:
>> 
>>  case BarrierSet::ModRef:
>> 
>> ?
> 
> That case never arises with the known set of barriers.  Let’s not pretend we know what code
> should go there.  Better to break in an obvious way if the situation changes, when we’ll know
> what needs to be done, rather than unintentionally covering a case incorrectly.
> 
> But on further consideration, I’m inclined to leave this as is in webrev.02, for consistency with
> all of the other similar switch statements in other code processors.  They can be cleaned up
> together as a separate RFE.

Sounds good.

> 
>> 
>> http://cr.openjdk.java.net/~twisti/8134994/webrev.02/
> 
> Looks good.

Thanks.