8026049: (bf) Intrinsify ByteBuffer.put{Int, Double, Float, ...} methods
John Rose
john.r.rose at oracle.com
Mon Mar 16 19:16:30 UTC 2015
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.
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.
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
More information about the core-libs-dev
mailing list