RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

David M. Lloyd david.lloyd at redhat.com
Wed Feb 18 14:32:21 UTC 2015


It's an awful lot of pain to avoid what IMO should be an obvious addition:

(Short|Character|Integer|Long).(get|put)(Little|Big)EndianBytes([value,] 
byte[] b, int offs)

This could (it seems to me) be easily intrinsified, is hugely useful 
both within and outside of the JDK, and fits perfectly well in the 
family of integral bit manipulations such as:

Integer.bitCount()
Integer.highestOneBit()
Integer.rotate*()
etc.

On 02/18/2015 08:16 AM, Vitaly Davidovich wrote:
> I don't think explicit barriers (i.e. Unsafe.xxxFence) should be removed as
> I don't think compiler can prove that it's safe to do so.  When value types
> come to be and get scalarized, it may be possible to create cheap
> synchronization types that are stack allocated yet are used for
> synchronization control.  For example, C# has a SpinLock struct (
> https://msdn.microsoft.com/en-us/library/system.threading.spinlock%28v=vs.110%29.aspx
> ).
>
> Also, I don't think Unsafe induced fences are part of JMM, current or
> future (at least I haven't heard that to be the case).
>
> sent from my phone
> On Feb 18, 2015 5:11 AM, "Andrew Haley" <aph at redhat.com> wrote:
>
>> On 02/18/2015 10:01 AM, Andrew Dinn wrote:
>>> On 17/02/15 19:21, Vitaly Davidovich wrote:
>>>> IMO I don't think such barriers should be removed just because EA is
>> able
>>>> to elide the heap allocation.
>>>
>>> Why not? Are you assuming that the programmer might be relying on a
>>> memory barrier being implied in interpreted/JITted code by the presence
>>> in the source of an allocation? If so then I am not sure the Java memory
>>> model justifies that assumption, especially so in the case EA optimises.
>>
>> It doesn't.
>>
>> There are essentially two ways to prevent unsafe publication of
>> objects with final fields: either emit a barrier at the end of the
>> constructor or track the reference to the newly-constructed object
>> until it is stored in memory.  That store to memory can be a releasing
>> store.  If the object does not escape that releasing store can be
>> eliminated.
>>
>> Andrew.
>>

-- 
- DML



More information about the core-libs-dev mailing list