RFR (S): 8140343: SEGV in DirectivesStack::getMatchingDirective

[Vladimir Kozlov]

I share Chris's concern - is _c1_store is always good choice and always 
defined. We still can have Server VM without C1 (PPC64). Or Zero. It 
should be taking into account.

If _c1_store is always present in all VM variants - it should be 
explained in comment.

Thanks,
Vladimir

On 10/28/15 5:15 PM, Nils Eliasson wrote:
> Still open for review.
>
> Regards,
> Nils
>
> On 2015-10-24 10:49, Nils Eliasson wrote:
>>
>> On 2015-10-23 22:39, Christian Thalinger wrote:
>>>> On Oct 22, 2015, at 11:03 PM, Nils Eliasson
>>>> <nils.eliasson at oracle.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> This fixes a bug when using a compiler that doesn't have compiler
>>>> directives. This is a temporary fix using the default directive for c1.
>>> What are the default directives for C1 and C2?  This fix is for JVMCI
>>> compilers and JVMCI compilers can only replace C2 in a tiered
>>> configuration.  Depending on what they are, wouldn’t it make more
>>> sense to use C2’s default directives?
>>
>> The default directive is a directive that is always installed, always
>> enabled and contains all the default values from vmflags and compile
>> commands. This is the directive all compilations are using if no
>> additional directives are installed.
>>>
>>>> In the future permanent fix all compilers will have directives by
>>>> default.
>>> How would that look like?
>>
>> Long story. It is an internal implementation detail to the structure
>> of compiler directives. Right now there is a bit of an overhead adding
>> a new compiler, even if only a single flag is used. The idea is to
>> have all directives contain all flags for all compilers - it might
>> sound expensive but will actually be more efficient. The most common
>> use case is only having the default directive, and in this case the
>> common flags wouldn't have to be duplicated for each compiler. The
>> profit in the JVMCI case is that all the common flags are valid and
>> usable without any workaround. The improvement is straightforward and
>> wont affect any use site but is big enough not to be the fix of this bug.
>>
>> //Nils
>>
>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8140343
>>>> webrev: http://cr.openjdk.java.net/~neliasso/8140343/webrev.01/
>>>>
>>>> Please review,
>>>> Nils
>>
>