Hi Ogata,
Thanks, I'll try with a Java equivalent of below structure. I can change
it later if needed. Stay tuned...
Regards, Peter
On 09/21/2017 11:39 AM, Kazunori Ogata wrote:
Hi Peter,
If you could extract from
the benchmark just the approximate shape of the data structure and
typical
Hi Peter,
> If you could extract from
> the benchmark just the approximate shape of the data structure and
> typical values it contains, I could create a JMH benchmark that tests
> just that part. Which would be appropriate to tune serialization code.
My colleague investigated the objects
On 09/20/2017 12:12 PM, Kazunori Ogata wrote:
By the way, I'm running the benchmark on POWER8 machine. Removing
volatile won't change the performance on x86.
I would like to compare different variants of optimization using final
fields. I won't compare it with current code that uses
Hi Ogata,
On 09/20/2017 12:12 PM, Kazunori Ogata wrote:
Hi Peter,
The benchmark is GradientBoostingTree of Intel HiBench [1]. HiBench is a
suite of programs using Hadoop or Spark, and GradientBoostingTree is a
Spark program. The source code (in Scala) is [2]. To build the code, you
need
Date: 2017/09/20 17:51
> Subject: Re: RFR: 8187033: [PPC] Imporve performance of
> ObjectStreamClass.getClassDataLayout()
>
> Hi Ogata,
>
> Do you have a source for your benchmark to share? I might be able to
> squeeze a little more from this approach but it would be e
Boehm <hbo...@google.com>
To: Kazunori Ogata <oga...@jp.ibm.com>
Cc: Peter Levart <peter.lev...@gmail.com>, core-libs-dev
<core-libs-dev@openjdk.java.net>
Date: 2017/09/19 05:47
Subject: Re: RFR: 8187033: [PPC] Imporve performance of
ObjectStreamClass.getClassDa
r comments.
Regards,
Ogata
From: Hans Boehm <hbo...@google.com>
To: Kazunori Ogata <oga...@jp.ibm.com>
Cc: Peter Levart <peter.lev...@gmail.com>, core-libs-dev
<core-libs-dev@openjdk.java.net>
Date: 2017/09/19 05:47
Subject: Re: RFR:
On Mon, Sep 18, 2017 at 10:52 AM, Kazunori Ogata wrote:
>
> Hi Peter,
>
> Peter Levart wrote on 2017/09/18 22:05:43:
>
> > On 09/18/2017 12:28 PM, Kazunori Ogata wrote:
> > > Hi Hans and Peter,
> > >
> > > Thank you for your comments.
> > >
> > >
Date: 2017/09/18 22:06
> Subject: Re: RFR: 8187033: [PPC] Imporve performance of
> ObjectStreamClass.getClassDataLayout()
>
> Hi Ogata,
>
> On 09/18/2017 12:28 PM, Kazunori Ogata wrote:
> > Hi Hans and Peter,
> >
> > Thank you for your comments.
> >
> &
<oga...@jp.ibm.com>, core-libs-dev
Date: 2017/09/18 05:51
Subject: Re: RFR: 8187033: [PPC] Imporve performance of
ObjectStreamClass.getClassDataLayout()
Hi,
On 09/15/17 19:54, Hans Boehm wrote:
The problem occurs if this is transformed (by hardware or compiler) to
1196 ClassDataSlot[] get
Levart <peter.lev...@gmail.com> wrote on 2017/09/18 05:51:07:
> From: Peter Levart <peter.lev...@gmail.com>
> To: Hans Boehm <hbo...@google.com>
> Cc: Kazunori Ogata <oga...@jp.ibm.com>, core-libs-dev d...@openjdk.java.net>
> Date: 2017/09/18 05:51
>
Hi,
On 09/15/17 19:54, Hans Boehm wrote:
The problem occurs if this is transformed (by hardware or compiler) to
1196 ClassDataSlot[] getClassDataLayout() throws
InvalidClassException {
1197 // REMIND: synchronize instead of relying on fullFence()?
1198
Cc: core-libs-dev <core-libs-dev@openjdk.java.net>
> Date: 2017/09/15 23:32
> Subject: Re: RFR: 8187033: [PPC] Imporve performance of
> ObjectStreamClass.getClassDataLayout()
>
> Hi,
>
> On 09/15/2017 07:12 AM, Kazunori Ogata wrote:
> > Hi Hans,
> >
> > Thank y
Hi,
On 09/15/2017 07:12 AM, Kazunori Ogata wrote:
Hi Hans,
Thank you for your comment
Hans Boehm wrote on 2017/09/15 09:44:56:
Just to be clear, the semi-plausible failure scenario here is that a
reader will see a non-null slots value, but then read an uninitialized
Hi Hans,
Thank you for your comment
Hans Boehm wrote on 2017/09/15 09:44:56:
> Just to be clear, the semi-plausible failure scenario here is that a
> reader will see a non-null slots value, but then read an uninitialized
> value from the ClassDataSlot array. This could
net
> Date: 2017/09/14 22:36
> Subject: Re: RFR: 8187033: [PPC] Imporve performance of
> ObjectStreamClass.getClassDataLayout()
> Sent by: "core-libs-dev" <core-libs-dev-boun...@openjdk.java.net>
>
> Hi,
>
> The repo's are closed in the short term for th
From: Peter Levart <peter.lev...@gmail.com>
To: Kazunori Ogata <oga...@jp.ibm.com>
Cc: core-libs-dev <core-libs-dev@openjdk.java.net>, Hans Boehm
<hbo...@google.com>, Aleksey Shipilev <sh...@redhat.com>
Date: 2017/09/04 17:45
Subject: Re: RFR: 8187033: [PPC] Impor
hat.com>
Date: 2017/09/04 18:13
Subject: Re: RFR: 8187033: [PPC] Imporve performance of
ObjectStreamClass.getClassDataLayout()
Hi Peter,
Thank you for fixing the code.
I updated webrev: http://cr.openjdk.java.net/~horii/8187033/webrev.02/
Regards,
Ogata
Peter Levart <peter.lev.
hbo...@google.com>, Aleksey Shipilev <sh...@redhat.com>
> Date: 2017/09/04 18:13
> Subject: Re: RFR: 8187033: [PPC] Imporve performance of
> ObjectStreamClass.getClassDataLayout()
>
> Hi Peter,
>
> Thank you for fixing the code.
>
> I updated webrev: http://cr.openjdk.java.net/~horii/8187033/webrev.02/
>
> Regards,
> Ogata
a...@jp.ibm.com>
> Cc: core-libs-dev <core-libs-dev@openjdk.java.net>, Hans Boehm
> <hbo...@google.com>, Aleksey Shipilev <sh...@redhat.com>
> Date: 2017/09/04 17:45
> Subject: Re: RFR: 8187033: [PPC] Imporve performance of
> ObjectStreamClass.getClassDataLayout()
Hi,
Maybe a more knowledgeable soul could shed some light into an internal
@Stable annotation...
It was meant to be used internally in the java.lang.invoke package, but
in JDK 9 it was made public, not exported, so it can be used in the
entire java.base module. There are already some usages
Ops, pressed SEND to quickly...
On 09/04/2017 10:45 AM, Peter Levart wrote:
ClassDataSlot[] getClassDataLayout() throws InvalidClassException {
ClassDataSlot[] slots = dataLayout;
if (slots == null) {
ClassDataSlot[] slots = getClassDataLayout0();
Hi Ogata,
On 09/04/2017 10:23 AM, Kazunori Ogata wrote:
Hi Peter,
Thank you for your comment. I thought the compiler must insert memory
fence at the end of object initializer, but I agree relying on it is not
correct w.r.t. JMM.
Then I'll take 1) 1) Put VarHandle.fullFence() between
azunori Ogata <oga...@jp.ibm.com>, core-libs-dev d...@openjdk.java.net>, Aleksey Shipilev <sh...@redhat.com>, Hans Boehm
> <hbo...@google.com>
> Date: 2017/09/04 17:06
> Subject: Re: RFR: 8187033: [PPC] Imporve performance of
> ObjectStreamClass.getClassDataLayout()
>
Hi Ogata,
On 09/04/2017 07:20 AM, Kazunori Ogata wrote:
4) Put reference to ClassDataSlot[] into a final field of an object, read
the final field immediately after the object creation, and store it to
non-volatile dataLayout. I think this is also correct based on the
semantics of final fields
Hi Aleksey and Hans,
I implemented four variations of changes and measured performance
improvement.
1) Put VarHandle.fullFence() between initialization of ClassDataSlot[] and
writing the reference to non-volatile dataLayout.
Webrev: http://cr.openjdk.java.net/~horii/8187033/webrev.01-fence/
On 02/09/17 03:53, Hans Boehm wrote:
> The problem is that all solutions that put all overhead on the writing side
> are inherently not correct with respect to the Java memory model. They rely
> on the necessary reader-side order (dataLayout read not reordered after
> read of ClassDataSlots that
com>, core-libs-dev
<core-libs-dev@openjdk.java.net>
Date: 2017/09/01 15:14
Subject: Re: RFR: 8187033: [PPC] Imporve performance of
ObjectStreamClass.getClassDataLayout()
On 08/31/2017 09:39 PM, Hans Boehm wrote:
>> I guess you can make VarHandle.fullFence() between
getClassDataLayo
On 08/31/2017 09:39 PM, Hans Boehm wrote:
>> I guess you can make VarHandle.fullFence() between getClassDataLayout0() and
>> storing it to the
>> non-volatile field...
>
> ... with the usual warning about this sort of thing:
>
> According to the JMM, it's not guaranteed to work, because the
On 08/31/2017 01:22 PM, Kazunori Ogata wrote:
> private ClassDataSlot[] dataLayout;
> private volatile ClassDataSlot[] dataLayout_tmp;
>
> ClassDataSlot[] getClassDataLayout() throws InvalidClassException {
> if (dataLayout == null) {
> dataLayout_tmp = getClassDataLayout0();
>
leksey Shipilev <sh...@redhat.com>
To: Kazunori Ogata <oga...@jp.ibm.com>, core-libs-dev@openjdk.java.net
Date: 2017/08/31 19:29
Subject: Re: RFR: 8187033: [PPC] Imporve performance of
ObjectStreamClass.getClassDataLayout()
On 08/31/2017 12:05 PM, Kazunori Ogata wrote:
&
com>
To: Kazunori Ogata <oga...@jp.ibm.com>, core-libs-dev@openjdk.java.net
Date: 2017/08/31 19:29
Subject: Re: RFR: 8187033: [PPC] Imporve performance of
ObjectStreamClass.getClassDataLayout()
On 08/31/2017 12:05 PM, Kazunori Ogata wrote:
> Bug report: https://bugs.openjdk.
On 08/31/2017 12:05 PM, Kazunori Ogata wrote:
> Bug report: https://bugs.openjdk.java.net/browse/JDK-8187033
> Webrev: http://cr.openjdk.java.net/~horii/8187033/webrev.00/
Alas, this change is incorrect. It introduces the race between readers and
writers of dataLayout
field. Which means,
Hi all,
Please review a change for JDK-8187033.
Bug report: https://bugs.openjdk.java.net/browse/JDK-8187033
Webrev: http://cr.openjdk.java.net/~horii/8187033/webrev.00/
This change removes a volatile qualifier of a private static variable used
by ObjectStreamClass.getClassDataLayout().
34 matches
Mail list logo