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" <a...@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
