Because that code was added and tested only for boxed objects (goal of
6934604) - I wanted to avoid wider effects of those changes.
I think we can remove the limitation now in jd9 sources since we have
enough time to tests it.
Regards,
Vladimir
On 4/16/15 10:07 AM, Andrew Haley wrote:
On 02
On 02/18/2015 08:59 PM, Vladimir Kozlov wrote:
> The code which eliminates MemBars for scalarized objects was added in jdk8:
>
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67
Right enough, but it only works with boxed objects. The
Precedent of the MemBarNode is needed by MemBarNo
On 18/02/15 20:59, Vladimir Kozlov wrote:
> The code which eliminates MemBars for scalarized objects was added in jdk8:
>
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67
>
> An other store barrier change was also pushed into jdk8:
>
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/
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
Thanks Vladimir. I was actually asking about the ByteBuffer elimination
itself; when I tried Andrew's example on 7u60 (i.e. a single method with a
ByteBuffer.wrap(...).getLong(...)), the ByteBuffer allocation was not
removed.
On Wed, Feb 18, 2015 at 3:59 PM, Vladimir Kozlov wrote:
> The code wh
The code which eliminates MemBars for scalarized objects was added in jdk8:
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67
An other store barrier change was also pushed into jdk8:
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/fcf521c3fbc6
I don't remember we did anything spec
On 02/18/2015 02:32 PM, David M. Lloyd wrote:
> 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
Ok, perhaps I misunderstood then since you mentioned Unsafe.storeFence() in
your earlier post and Vladimir said they were debating whether these fences
should be removed. If you guys were talking only about the final field
fence, then my bad, I don't disagree with removing those if the object
does
On 02/18/2015 02:16 PM, 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.
Nobody thinks that explicit barriers (i.e. Unsafe.xxxFence) should be
removed.
We're talking about fences at t
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 w
Indeed, that's quite nice and not what I saw in java 7 so good to see that
this case is EA'd out. Does anyone know if there was EA work done in java
9 or is this simply inlining policy change that makes EA work (as John
alluded to)?
sent from my phone
On Feb 18, 2015 6:13 AM, "Andrew Haley" wrot
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 c
On 02/18/2015 09:15 AM, Andrew Haley wrote:
> On 18/02/15 09:14, Florian Weimer wrote:
>> Wow, looks nice. What OpenJDK build did you use? I want to see if this
>> happens on x86_64, too.
>
> I'm working on JDK9. You don't have this code yet. I'll do an x86
> build.
0x7f2948acbf8c: mov
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 impl
IMO I don't think such barriers should be removed just because EA is able
to elide the heap allocation.
On Tue, Feb 17, 2015 at 2:15 PM, Vladimir Kozlov wrote:
> There was discussion should we remove such barriers or not because they
> create memory operations ordering which could be different i
There was discussion should we remove such barriers or not because they
create memory operations ordering which could be different if we remove
them.
To eliminate them we need to add 'precedent' edge to store's membar as
we do, for example, for loads:
if (field->is_volatile()) {
// Mem
What do you mean exactly? I don't think inlining "hides" anything, so the
explicit fence should still be there for EA to see (and preserve).
sent from my phone
On Feb 17, 2015 1:58 PM, "Andrew Haley" wrote:
> On 02/17/2015 06:42 PM, John Rose wrote:
> > The remaining store fence is probably a bu
On 02/17/2015 06:42 PM, John Rose wrote:
> The remaining store fence is probably a bug. A store fence for scalarized
> (lifted-out-of-memory) final fields should go away, since the fields are not
> actually stored in heap memory.
After inlining how would escape analysis know that the store fenc
On Feb 17, 2015, at 6:22 AM, Andrew Haley wrote:
>
> Everything gets inlined nicely and the ByteBuffer is not created, but
> a store fence remains because of the final fields in HeapByteBuffer.
Wow, that got closer to the goal than I expected. In general, the EA analysis
can fail "at random" b
On 02/17/2015 10:53 AM, Andrew Haley wrote:
> I see. So the question could also be whether escape analysis would
> notice that a ByteBuffer does not escape. I hope to know that soon.
Close but no cigar.
long getLong(byte[] bytes, int i) {
return ByteBuffer.wrap(bytes).getLong(i);
Am 17.02.2015 um 04:35 schrieb John Rose:
On Feb 14, 2015, at 12:01 AM, Andrew Haley wrote:
On 02/14/2015 12:09 AM, John Rose wrote:
We also need Unsafe.getIntMisaligned, etc., which wire through to whatever
second-best mechanism the platform offers.
Indeed. I'm intending to prototype a des
FWIW, when I checked, ByteBuffer.wrap(...).getXXX() type of code didn't EA
out the BB; it seems the call chain is too complex for EA. I checked 7u60
though, so maybe newer versions are different.
sent from my phone
On Feb 17, 2015 5:53 AM, "Andrew Haley" wrote:
> On 02/17/2015 10:49 AM, Florian
Am 17.02.2015 um 11:53 schrieb Andrew Haley:
On 02/17/2015 10:49 AM, Florian Weimer wrote:
That is, the byte array is supplied by the caller, and if we wanted to
use a ByteBuffer, we would have to allocate a fresh one on every
iteration. In this case, neither of the two alternatives you list a
On 02/17/2015 10:49 AM, Florian Weimer wrote:
> On 02/17/2015 11:22 AM, Andrew Haley wrote:
>>> You'll still have to allocate a wrapping ByteBuffer object to use them.
>>> I expect that makes them unattractive in many cases.
>>
>> Hmm. I'm having a hard time trying to understand why. If you need
On 02/17/2015 11:22 AM, Andrew Haley wrote:
>> You'll still have to allocate a wrapping ByteBuffer object to use them.
>> I expect that makes them unattractive in many cases.
>
> Hmm. I'm having a hard time trying to understand why. If you need to
> do a lot of accesses the allocation of the By
On 02/17/2015 10:15 AM, Florian Weimer wrote:
> On 02/17/2015 11:00 AM, Andrew Haley wrote:
>> On 02/17/2015 09:39 AM, Florian Weimer wrote:
>>> On 02/14/2015 01:09 AM, John Rose wrote:
These queries need to go into Unsafe.
We also need Unsafe.getIntMisaligned, etc., which wire through to
On 02/17/2015 11:00 AM, Andrew Haley wrote:
> On 02/17/2015 09:39 AM, Florian Weimer wrote:
>> On 02/14/2015 01:09 AM, John Rose wrote:
>>> These queries need to go into Unsafe.
>>> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever
>>> second-best mechanism the platform of
On 02/17/2015 09:39 AM, Florian Weimer wrote:
> On 02/14/2015 01:09 AM, John Rose wrote:
>> These queries need to go into Unsafe.
>> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever
>> second-best mechanism the platform offers.
>
> The safe variants should go into the ja
On 02/14/2015 11:10 PM, Dean Long wrote:
> Even if linux-aarch64 always allows unaligned, checking only for
> "aarch64" is not future-proof
> because it doesn't take the OS into account.
Surely a simple test case is sufficient to ensure that the platform
supports misaligned accesses? Then new po
On 02/14/2015 01:09 AM, John Rose wrote:
> These queries need to go into Unsafe.
> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever
> second-best mechanism the platform offers.
The safe variants should go into the java.lang.Integer etc. classes
IMHO. Even the JDK has qu
On Feb 14, 2015, at 12:01 AM, Andrew Haley wrote:
>
> On 02/14/2015 12:09 AM, John Rose wrote:
>> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever
>> second-best mechanism the platform offers.
>
> Indeed. I'm intending to prototype a design for those next week. OK?
On 02/16/2015 11:02 AM, Alan Bateman wrote:
> On 14/02/2015 22:10, Dean Long wrote:
>>
>> Even if linux-aarch64 always allows unaligned, checking only for
>> "aarch64" is not future-proof
>> because it doesn't take the OS into account. However, I really don't
>> like having to enumerate
>> all r
On 14/02/2015 22:10, Dean Long wrote:
Even if linux-aarch64 always allows unaligned, checking only for
"aarch64" is not future-proof
because it doesn't take the OS into account. However, I really don't
like having to enumerate
all relevant platforms in multiple places in shared code, so I
di
On 14/02/15 22:10, Dean Long wrote:
> On 2/14/2015 12:07 AM, Andrew Haley wrote:
>> On 02/13/2015 10:52 PM, Dean Long wrote:
>>
>>> My understanding is that whether or not aarch64 allows unaligned
>>> accesses is based on a system setting, so this change is too
>>> simplistic.
>>
>> Disabling unali
On 2/14/2015 12:07 AM, Andrew Haley wrote:
On 02/13/2015 10:52 PM, Dean Long wrote:
My understanding is that whether or not aarch64 allows unaligned
accesses is based on a system setting, so this change is too
simplistic.
Disabling unaligned access would be a really perverse thing to do, and
I
On 02/13/2015 10:52 PM, Dean Long wrote:
> My understanding is that whether or not aarch64 allows unaligned
> accesses is based on a system setting, so this change is too
> simplistic.
Disabling unaligned access would be a really perverse thing to do, and
I suspect that GCC and glibc already assu
On 02/14/2015 12:09 AM, John Rose wrote:
> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever
> second-best mechanism the platform offers.
Indeed. I'm intending to prototype a design for those next week. OK?
Andrew.
On Feb 13, 4:29pm, vladimir.koz...@oracle.com (Vladimir Kozlov) wrote:
-- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
| On 2/13/15 4:22 PM, Dean Long wrote:
| > There is a system register bit to read, but I don't think it can be
| > accessed by an application, only
On 2/13/15 4:22 PM, Dean Long wrote:
There is a system register bit to read, but I don't think it can be
accessed by an application, only the kernel.
If the OS won't provide this information, you could do something similar
to safeFetchN and catch the
resulting SIGBUS.
Yes, I agree it could be d
There is a system register bit to read, but I don't think it can be
accessed by an application, only the kernel.
If the OS won't provide this information, you could do something similar
to safeFetchN and catch the
resulting SIGBUS.
dl
On 2/13/2015 4:05 PM, Vladimir Kozlov wrote:
x86 has flag U
These queries need to go into Unsafe.
We also need Unsafe.getIntMisaligned, etc., which wire through to whatever
second-best mechanism the platform offers.
— John
x86 has flag UseUnalignedLoadStores which is set to true depending on
which version of CPU VM runs. The CPU version is determined based on
CPUID instruction results.
Does AARCH64 has something similar?
Regards,
Vladimir
On 2/13/15 3:41 PM, Dean Long wrote:
On 2/13/2015 3:04 PM, chris...@zoul
On 2/13/2015 3:04 PM, chris...@zoulas.com wrote:
On Feb 13, 2:52pm, dean.l...@oracle.com (Dean Long) wrote:
-- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
| My understanding is that whether or not aarch64 allows unaligned=20
| accesses is based on a
| system settin
On Feb 13, 2:52pm, dean.l...@oracle.com (Dean Long) wrote:
-- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer
| My understanding is that whether or not aarch64 allows unaligned=20
| accesses is based on a
| system setting, so this change is too simplistic. I would pref
My understanding is that whether or not aarch64 allows unaligned
accesses is based on a
system setting, so this change is too simplistic. I would prefer that
this was controlled with
something more flexible, like "sun.cpu.unaligned".
dl
On 2/13/2015 5:38 AM, Andrew Haley wrote:
java.nio.Di
Changes are fine.
I agree with Alan. Please, wait when we merge aarch64 stage into jdk9/dev and then push this fix into jdk9 (by sponsor).
We should finish testing of stage repo "soon".
Thanks,
Vladimir
On 2/13/15 8:07 AM, Andrew Haley wrote:
On 02/13/2015 04:05 PM, Alan Bateman wrote:
On 1
On 02/13/2015 04:05 PM, Alan Bateman wrote:
> On 13/02/2015 13:38, Andrew Haley wrote:
>> java.nio.DirectByteBuffer.getXXX is slow for types larger than byte
>> because the runtime does not know that AArch64 can perform unaligned
>> memory accesses.
>>
>> The problem is due to this code in java.n
On 13/02/2015 13:38, Andrew Haley wrote:
java.nio.DirectByteBuffer.getXXX is slow for types larger than byte
because the runtime does not know that AArch64 can perform unaligned
memory accesses.
The problem is due to this code in java.nio.Bits.unaligned():
unaligned = arch.equals("i3
48 matches
Mail list logo
