RFR (XS): 8007901 SA: Don't read flag values as constants

[David Holmes]

Thanks for clarifying this Staffan, I see now how this was setup wrong 
in the first place. You are using the right mechanism now.

I'm not sure UseTLAB warrants its own accessor in VM anymore as the two 
uses of it can simply ask for the flag value directly. Your call.

Thanks,
David

On 12/02/2013 8:19 PM, Staffan Larsen wrote:
> The values are initialized at VM compile time in the VMStructs::localHotSpotVMIntConstants array. I don't think we want to modify SA so that values of int constants is made into a dynamic lookup. Or at least, that is a fairly significant change to SA. The problem here was to think that UseTLAB is a constant when it isn't.
>
> Yes, I thought about a regression test for this, but the valuable test would be to verify that no command line flag values are read as constants, and I don't see how I could write that.
>
> Thanks,
> /Staffan
>
> On 12 feb 2013, at 01:20, David Holmes <David.Holmes at oracle.com> wrote:
>
>> On 10/02/2013 5:06 AM, Staffan Larsen wrote:
>>> Please review this small patch to avoid reading flag values in SA as constants. Reading them as constants  means SA will only see the default value for these flags. Instead the infrastructure in SA to read command line flags should be used. In addition the value if EnableInvokeDynamic is never used, so I removed that from SA.
>>
>> Isn't the real problem in the way db is initialized with the values for these flags? ie shouldn't db.lookupIntConstant("UseTLAB").intValue() be returning the actual value of UseTLAB as it occurs in the VM ?
>>
>> Also we need a regression test for this as obviously it ain't being tested! :(
>>
>> Thanks,
>> David
>>
>>> webrev: http://cr.openjdk.java.net/~sla/8007901/webrev.00/
>>> bug: http://bugs.sun.com/view_bug.do?bug_id=8007901 (not yet visible)
>>>
>>> Thanks,
>>> /Staffan
>>>
>