On 17/03/2015 5:16 AM, John Rose wrote:
On Mar 16, 2015, at 2:29 AM, Andrew Haley <a...@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
