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

David Holmes david.holmes at oracle.com
Sun Feb 17 20:23:42 PST 2013

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/viewbug.do?bugid=8007901 (not yet visible)

Thanks, /Staffan

More information about the serviceability-dev mailing list