8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods

[Andrew Haley]

On 03/16/2015 11:36 AM, David Holmes wrote:
> On 16/03/2015 7:29 PM, Andrew Haley wrote:
>> On 16/03/15 00:40, David Holmes wrote:
>>> Experimental options are supposed to be opt-in only via
>>> UnlockExperimentalVMOptions. You presently have the experimental
>>> UseUnalignedAccesses being turned on unconditionally on those
>>> architectures that support it.
>>
>> Well, it works.  I guess this could be changed to be a product option,
>> but it's only really needed for testing.  And aren't product options
>> supposed to be properly documented for all users?
>>
>> In other words: please don't say "don't do that."  Please tell me what
>> I should do instead.  All suggestions are welcome, really because I'm
>> rather stuck.
> 
> Either it should be an experimental option, in which case the logic that 
> sets the flag on should check that UnlockExperimentalVMOptions is also 
> on (else do nothing).

But UnlockExperimentalVMOptions is handled by the option processing
already.

> (Though this would still be a unusual use-case for 
> an experimental option as the intent is that the user chooses to turn 
> them on directly.)
> 
> Or it should not be an experimental option.

We need a flag which defaults to whatever is right for the platform
(so it must be set in the back ends) but can be overridden by testing.
What we have right now fits that requirement.  I can see no way to do
what I think you're asking for with the current option machinery.  I
certainly don't think this should be a product flag.

Andrew.