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

[David Holmes]

On 17/03/2015 5:16 AM, John Rose wrote:
> On Mar 16, 2015, at 2:29 AM, Andrew Haley <aph at redhat.com> 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.
>
> David has a point about experimental options; they have an opt-in sense to them.

Actually John it has been pointed out to me that my interpretation of 
experimental options is not correct. It seems we already have a number 
of "experimental" options that are on by default and the "experimental" 
aspect is the turning of them off.

> Since the option provides control for product behavior, without an explicit opt-in, it should either be a product flag or a diagnostic flag.
>
> I suggest keeping the more direct name (Use* not Disable*) and making it a diagnostic flag.
>
> As a diagnostic flag it does not require a CCC request, since it is not for JVM customers to use.  Its purpose is testing and field diagnosis by implementation engineers.  Similar flags are ScavengeRootsInCode, LogEventsBufferEntries, and ParGCCardsPerStrideChunk.

I think diagnostic works better here too.

Thanks,
David

> Typical uses:  On platforms which support unaligned accesses, do differential performance testing to verify that the switch is correctly set for the platform.  On platforms which do not, if hardware or JIT upgrades supply a faster unaligned access, do differential regression testing with the new feature in play.
>
> — John
>