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

Peter Levart peter.levart at gmail.com
Mon Mar 16 12:43:46 UTC 2015


On 03/16/2015 01:25 PM, Andrew Haley wrote:
> 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.

Hi Andrew,

I think the confusion is caused by UseUnalignedAccesses flag (part of a 
public interface unless it is experimental - the command line options) 
that is used internally to communicate the cpu default to the 
implementation of Unsafe.unalignedAccess() method. What if:

- you define an internal constant SUPPORTS_UNALIGNED_ACCESSES (I don't 
know how to do that correctly) in per-cpu vm_version_cpu.hpp files.
- rename UseUnalignedAccesses to EmulateUnalignedAccesses (reverse the 
meaning, so that default can be false which must be for experimental 
options)
- implement Unsafe.unalignedAccess() to return: 
SUPPORTS_UNALIGNED_ACCESSES && !EmulateUnalignedAccesses ...

Regards, Peter




More information about the core-libs-dev mailing list