You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Aleksey Shipilev <al...@gmail.com> on 2008/04/15 00:04:53 UTC
[general][performance] Serialization patches need committer attention
Hi all,
As you might noticed, there is active work on serialization
performance improvements [1]. So far we had committed 4 patches
concerning scalability and boosted the performance on multi-threaded
serialization benchmarks more than 2x times. And this is not the end
of the journey: more issues coming.
Dear committers, can you please review and commit the patches in ready JIRAs?
I will be happy if these two committed:
a. [classlib][luni][performance] ObjectInputStream/ObjectOutputStream
can use optimized API for accessing fields - available at [2]
This issue moves the setField/getField functionality to ObjectAccessor
utility class. This eliminates one serious problem: creation of string
during field name lookup on native side. The second advantage is that
this solution checks security on accessor creation rather than on
every call (like Reflection API does). This improvement gives another
30-120% boost for serialization workload.
I expect more with rewriting these accessors on magics, thus
eliminating JNI overhead and native-side work. Those who interested in
this topic, feel free to join in corresponding JIRA [3].
b. [classlib][luni][performance] j.u.IdentityHashMap ariphmetic
improvements - available at [4]
After the moving of ObjectStreamClass cache to ThreadLocalCache [5],
performance of serialization depends on ThreadLocal performance and
then on IdentityHashMap performance. Simple benchmark shows that
ThreadLocal performance is devastating: 50x slower than Sun 1.6.0_05
[6]. This is very first ready patch from that chain of issues. It
brings up +300% boost on ThreadLocal benchmark and +10% boost to
serialization benchmark.
Thanks,
Aleksey.
[1] https://issues.apache.org/jira/browse/HARMONY-5632
[2] https://issues.apache.org/jira/browse/HARMONY-5722 (ready)
[3] https://issues.apache.org/jira/browse/HARMONY-5725
[4] https://issues.apache.org/jira/browse/HARMONY-5718 (ready)
[5] https://issues.apache.org/jira/browse/HARMONY-5633
[6] https://issues.apache.org/jira/browse/HARMONY-5703
Re: [general][performance] Serialization patches need committer attention
Posted by Aleksey Shipilev <al...@gmail.com>.
Thanks, Tony!
On Fri, Apr 18, 2008 at 3:01 PM, Tony Wu <wu...@gmail.com> wrote:
> ok, my mistake. it passes for me now. Sorry for your rebuild...
> it has been integrated at r649457 and r649459. I failed to commit in
> one run because of a "RA layer request failed".
>
>
>
> On 4/18/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > Tony,
> >
> > Hm... I had run all JUnit tests before attaching the patch to JIRA, no
> > crashes due to linkage errors were occurred. Anyway, I had rebuilt
> > classlib several times with H5756 onboard, run the AUTH tests and
> > can't reproduce the linkage error you mentioned. I had either running
> > incremental rebuild or full clean-rebuild, no failure. Makefiles are
> > already modified in the patch, so the patch remain the same.
> >
> > I'm afraid the problem is in your environment, would you please
> > rebuild from scratch? If the issue is still reproduced, I need more
> > info on the failure.
> >
> > Thanks,
> > Aleksey.
> >
> > On Fri, Apr 18, 2008 at 7:51 AM, Tony Wu <wu...@gmail.com> wrote:
> > > Hi, Aleksey
> > > just did a quick look at 5756, seems there will be some
> > > unsatisfiedlink error in auth and security module because the ois.c
> > > has been removed. would you please rebuild the native with your patch
> > > and verify if I'm correct. And please don't forget to modify the
> > > makefile of linux accordingly. I'll be offline for several hours,
> > > sorry if I can't reply immediately.
> > >
> > >
> > >
> > > On 4/17/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > Hi,
> > > >
> > > > There are two additional issues waiting for committers attention:
> > > > https://issues.apache.org/jira/browse/HARMONY-5756
> > > > https://issues.apache.org/jira/browse/HARMONY-5718
> > > >
> > > > Can anyone review and commit them?
> > > >
> > > > Thanks,
> > > > Aleksey.
> > > >
> > > > On Tue, Apr 15, 2008 at 5:27 PM, Aleksey Shipilev
> > > > <al...@gmail.com> wrote:
> > > > > Tony,
> > > > >
> > > > > I had fixed the issues with JUnit tests, it was my oversight about
> > > > > handling NoSuchFieldError exceptions.
> > > > > Now all seem to be OK, LUNI tests were passed.
> > > > >
> > > > > Thanks,
> > > > > Aleksey.
> > > > >
> > > > > On Tue, Apr 15, 2008 at 11:14 AM, Aleksey Shipilev
> > > > >
> > > > >
> > > > > <al...@gmail.com> wrote:
> > > > > > Hm, I didn't expect this, will take a look, thanks.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 15, 2008 at 11:00 AM, Tony Wu <wu...@gmail.com> wrote:
> > > > > > > Aleksey,
> > > > > > > I think keep the benchmark somewhere such as JIRA is also ok.
> > > > > > >
> > > > > > > 7 serialization related errors in Collections2Test after applied your
> > > > > > > patch. All of them looked like below.
> > > > > > >
> > > > > > > zeroLengthElementArray
> > > > > > >
> > > > > > > java.lang.NoSuchFieldError: zeroLengthElementArray at
> > > > > > > org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:54)
> > > > > > > at org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:56)
> > > > > > > at java.io.ObjectStreamField.getFieldID(ObjectStreamField.java:59) at
> > > > > > > java.io.ObjectInputStream.readFieldValues(ObjectInputStream.java:1133)
> > > > > > > at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:433)
> > > > > > > at java.io.ObjectInputStream.readObjectForClass(ObjectInputStream.java:1415)
> > > > > > > at java.io.ObjectInputStream.readHierarchy(ObjectInputStream.java:1322)
> > > > > > > at java.io.ObjectInputStream.readNewObject(ObjectInputStream.java:1978)
> > > > > > > at java.io.ObjectInputStream.readNonPrimitiveContent(ObjectInputStream.java:821)
> > > > > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:2130)
> > > > > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:285) at
> > > > > > > tests.util.SerializationTester.readObject(SerializationTester.java:171)
> > > > > > > at tests.util.SerializationTester.assertCompabilityEquals(SerializationTester.java:142)
> > > > > > > at org.apache.harmony.luni.tests.java.util.Collections2Test.test_checkedCollectionSerializationCompatability(Collections2Test.java:418)
> > > > > > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > > > > > Thanks, Tony!
> > > > > > > >
> > > > > > > > There is microbenchmark in [1], is it too big for regression test?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Aleksey.
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > > >
> > > > > > > > On Tue, Apr 15, 2008 at 7:08 AM, Tony Wu <wu...@gmail.com> wrote:
> > > > > > > > > Hi, Aleksey
> > > > > > > > > I'm looking at 5722. I agree with you on leveraging the Accessor but I
> > > > > > > > > think it would be good if you can post some micro-benchmark on this
> > > > > > > > > JIRA so that we can utilize it as regression test in future.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > > > > > > > Hi all,
> > > > > > > > > >
> > > > > > > > > > As you might noticed, there is active work on serialization
> > > > > > > > > > performance improvements [1]. So far we had committed 4 patches
> > > > > > > > > > concerning scalability and boosted the performance on multi-threaded
> > > > > > > > > > serialization benchmarks more than 2x times. And this is not the end
> > > > > > > > > > of the journey: more issues coming.
> > > > > > > > > >
> > > > > > > > > > Dear committers, can you please review and commit the patches in ready JIRAs?
> > > > > > > > > > I will be happy if these two committed:
> > > > > > > > > >
> > > > > > > > > > a. [classlib][luni][performance] ObjectInputStream/ObjectOutputStream
> > > > > > > > > > can use optimized API for accessing fields - available at [2]
> > > > > > > > > > This issue moves the setField/getField functionality to ObjectAccessor
> > > > > > > > > > utility class. This eliminates one serious problem: creation of string
> > > > > > > > > > during field name lookup on native side. The second advantage is that
> > > > > > > > > > this solution checks security on accessor creation rather than on
> > > > > > > > > > every call (like Reflection API does). This improvement gives another
> > > > > > > > > > 30-120% boost for serialization workload.
> > > > > > > > > >
> > > > > > > > > > I expect more with rewriting these accessors on magics, thus
> > > > > > > > > > eliminating JNI overhead and native-side work. Those who interested in
> > > > > > > > > > this topic, feel free to join in corresponding JIRA [3].
> > > > > > > > > >
> > > > > > > > > > b. [classlib][luni][performance] j.u.IdentityHashMap ariphmetic
> > > > > > > > > > improvements - available at [4]
> > > > > > > > > > After the moving of ObjectStreamClass cache to ThreadLocalCache [5],
> > > > > > > > > > performance of serialization depends on ThreadLocal performance and
> > > > > > > > > > then on IdentityHashMap performance. Simple benchmark shows that
> > > > > > > > > > ThreadLocal performance is devastating: 50x slower than Sun 1.6.0_05
> > > > > > > > > > [6]. This is very first ready patch from that chain of issues. It
> > > > > > > > > > brings up +300% boost on ThreadLocal benchmark and +10% boost to
> > > > > > > > > > serialization benchmark.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Aleksey.
> > > > > > > > > >
> > > > > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > > > > > [2] https://issues.apache.org/jira/browse/HARMONY-5722 (ready)
> > > > > > > > > > [3] https://issues.apache.org/jira/browse/HARMONY-5725
> > > > > > > > > > [4] https://issues.apache.org/jira/browse/HARMONY-5718 (ready)
> > > > > > > > > > [5] https://issues.apache.org/jira/browse/HARMONY-5633
> > > > > > > > > > [6] https://issues.apache.org/jira/browse/HARMONY-5703
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Tony Wu
> > > > > > > > > China Software Development Lab, IBM
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > >
> > > > > > > Tony Wu
> > > > > > > China Software Development Lab, IBM
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > >
> > > Tony Wu
> > > China Software Development Lab, IBM
> > >
> >
>
>
> --
>
>
> Tony Wu
> China Software Development Lab, IBM
>
Re: [general][performance] Serialization patches need committer attention
Posted by Tony Wu <wu...@gmail.com>.
ok, my mistake. it passes for me now. Sorry for your rebuild...
it has been integrated at r649457 and r649459. I failed to commit in
one run because of a "RA layer request failed".
On 4/18/08, Aleksey Shipilev <al...@gmail.com> wrote:
> Tony,
>
> Hm... I had run all JUnit tests before attaching the patch to JIRA, no
> crashes due to linkage errors were occurred. Anyway, I had rebuilt
> classlib several times with H5756 onboard, run the AUTH tests and
> can't reproduce the linkage error you mentioned. I had either running
> incremental rebuild or full clean-rebuild, no failure. Makefiles are
> already modified in the patch, so the patch remain the same.
>
> I'm afraid the problem is in your environment, would you please
> rebuild from scratch? If the issue is still reproduced, I need more
> info on the failure.
>
> Thanks,
> Aleksey.
>
> On Fri, Apr 18, 2008 at 7:51 AM, Tony Wu <wu...@gmail.com> wrote:
> > Hi, Aleksey
> > just did a quick look at 5756, seems there will be some
> > unsatisfiedlink error in auth and security module because the ois.c
> > has been removed. would you please rebuild the native with your patch
> > and verify if I'm correct. And please don't forget to modify the
> > makefile of linux accordingly. I'll be offline for several hours,
> > sorry if I can't reply immediately.
> >
> >
> >
> > On 4/17/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > Hi,
> > >
> > > There are two additional issues waiting for committers attention:
> > > https://issues.apache.org/jira/browse/HARMONY-5756
> > > https://issues.apache.org/jira/browse/HARMONY-5718
> > >
> > > Can anyone review and commit them?
> > >
> > > Thanks,
> > > Aleksey.
> > >
> > > On Tue, Apr 15, 2008 at 5:27 PM, Aleksey Shipilev
> > > <al...@gmail.com> wrote:
> > > > Tony,
> > > >
> > > > I had fixed the issues with JUnit tests, it was my oversight about
> > > > handling NoSuchFieldError exceptions.
> > > > Now all seem to be OK, LUNI tests were passed.
> > > >
> > > > Thanks,
> > > > Aleksey.
> > > >
> > > > On Tue, Apr 15, 2008 at 11:14 AM, Aleksey Shipilev
> > > >
> > > >
> > > > <al...@gmail.com> wrote:
> > > > > Hm, I didn't expect this, will take a look, thanks.
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Apr 15, 2008 at 11:00 AM, Tony Wu <wu...@gmail.com> wrote:
> > > > > > Aleksey,
> > > > > > I think keep the benchmark somewhere such as JIRA is also ok.
> > > > > >
> > > > > > 7 serialization related errors in Collections2Test after applied your
> > > > > > patch. All of them looked like below.
> > > > > >
> > > > > > zeroLengthElementArray
> > > > > >
> > > > > > java.lang.NoSuchFieldError: zeroLengthElementArray at
> > > > > > org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:54)
> > > > > > at org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:56)
> > > > > > at java.io.ObjectStreamField.getFieldID(ObjectStreamField.java:59) at
> > > > > > java.io.ObjectInputStream.readFieldValues(ObjectInputStream.java:1133)
> > > > > > at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:433)
> > > > > > at java.io.ObjectInputStream.readObjectForClass(ObjectInputStream.java:1415)
> > > > > > at java.io.ObjectInputStream.readHierarchy(ObjectInputStream.java:1322)
> > > > > > at java.io.ObjectInputStream.readNewObject(ObjectInputStream.java:1978)
> > > > > > at java.io.ObjectInputStream.readNonPrimitiveContent(ObjectInputStream.java:821)
> > > > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:2130)
> > > > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:285) at
> > > > > > tests.util.SerializationTester.readObject(SerializationTester.java:171)
> > > > > > at tests.util.SerializationTester.assertCompabilityEquals(SerializationTester.java:142)
> > > > > > at org.apache.harmony.luni.tests.java.util.Collections2Test.test_checkedCollectionSerializationCompatability(Collections2Test.java:418)
> > > > > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > > > > Thanks, Tony!
> > > > > > >
> > > > > > > There is microbenchmark in [1], is it too big for regression test?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Aleksey.
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > >
> > > > > > > On Tue, Apr 15, 2008 at 7:08 AM, Tony Wu <wu...@gmail.com> wrote:
> > > > > > > > Hi, Aleksey
> > > > > > > > I'm looking at 5722. I agree with you on leveraging the Accessor but I
> > > > > > > > think it would be good if you can post some micro-benchmark on this
> > > > > > > > JIRA so that we can utilize it as regression test in future.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > As you might noticed, there is active work on serialization
> > > > > > > > > performance improvements [1]. So far we had committed 4 patches
> > > > > > > > > concerning scalability and boosted the performance on multi-threaded
> > > > > > > > > serialization benchmarks more than 2x times. And this is not the end
> > > > > > > > > of the journey: more issues coming.
> > > > > > > > >
> > > > > > > > > Dear committers, can you please review and commit the patches in ready JIRAs?
> > > > > > > > > I will be happy if these two committed:
> > > > > > > > >
> > > > > > > > > a. [classlib][luni][performance] ObjectInputStream/ObjectOutputStream
> > > > > > > > > can use optimized API for accessing fields - available at [2]
> > > > > > > > > This issue moves the setField/getField functionality to ObjectAccessor
> > > > > > > > > utility class. This eliminates one serious problem: creation of string
> > > > > > > > > during field name lookup on native side. The second advantage is that
> > > > > > > > > this solution checks security on accessor creation rather than on
> > > > > > > > > every call (like Reflection API does). This improvement gives another
> > > > > > > > > 30-120% boost for serialization workload.
> > > > > > > > >
> > > > > > > > > I expect more with rewriting these accessors on magics, thus
> > > > > > > > > eliminating JNI overhead and native-side work. Those who interested in
> > > > > > > > > this topic, feel free to join in corresponding JIRA [3].
> > > > > > > > >
> > > > > > > > > b. [classlib][luni][performance] j.u.IdentityHashMap ariphmetic
> > > > > > > > > improvements - available at [4]
> > > > > > > > > After the moving of ObjectStreamClass cache to ThreadLocalCache [5],
> > > > > > > > > performance of serialization depends on ThreadLocal performance and
> > > > > > > > > then on IdentityHashMap performance. Simple benchmark shows that
> > > > > > > > > ThreadLocal performance is devastating: 50x slower than Sun 1.6.0_05
> > > > > > > > > [6]. This is very first ready patch from that chain of issues. It
> > > > > > > > > brings up +300% boost on ThreadLocal benchmark and +10% boost to
> > > > > > > > > serialization benchmark.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Aleksey.
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > > > > [2] https://issues.apache.org/jira/browse/HARMONY-5722 (ready)
> > > > > > > > > [3] https://issues.apache.org/jira/browse/HARMONY-5725
> > > > > > > > > [4] https://issues.apache.org/jira/browse/HARMONY-5718 (ready)
> > > > > > > > > [5] https://issues.apache.org/jira/browse/HARMONY-5633
> > > > > > > > > [6] https://issues.apache.org/jira/browse/HARMONY-5703
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Tony Wu
> > > > > > > > China Software Development Lab, IBM
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > >
> > > > > > Tony Wu
> > > > > > China Software Development Lab, IBM
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> >
> >
> > Tony Wu
> > China Software Development Lab, IBM
> >
>
--
Tony Wu
China Software Development Lab, IBM
Re: [general][performance] Serialization patches need committer attention
Posted by Alexey Varlamov <al...@gmail.com>.
Moreover, r649459 added a security breach in ObjectAccessor and
Aleksey already asked in HARMONY-5756 to revert it.
Don't hurry, be happy ;)
Regards,
Alexey
2008/4/21, Tony Wu <wu...@gmail.com>:
> Hi,Mark
> Thanks for pointing out. To remove this dependency, I think we can
> move the ObjectAccessor classes to luni or another separate module.
>
> On 4/18/08, Mark Hindess <ma...@googlemail.com> wrote:
> >
> > Tony, Aleksey,
> >
> > This patch works for me on linux from a fresh checkout. So I suspect
> > Tony has a local problem too.
> >
> > One thing I am cautious about is that this patch (and the earlier patch
> > committed as part of HARMONY-5722) add a dependency from misc.jar to
> > luni.jar that was not there before. This is not a problem in itself but
> > I think we should discuss such changes on the list before making them.
> >
> > In this case it probably isn't a big problem since the misc module is
> > fairly small and none of the misc dependencies are new to the luni
> > module.
> >
> > Incidentally, isn't the org.apache.harmony.awt.nativebridge package only
> > required by the misc module for testing? Shouldn't the MANIFEST reflect
> > this?
> >
> > Regards,
> > Mark.
> >
> > On 18 April 2008 at 10:26, "Aleksey Shipilev" <al...@gmail.com>
> > wrote:
> > > Tony,
> > >
> > > Hm... I had run all JUnit tests before attaching the patch to JIRA,
> > > no crashes due to linkage errors were occurred. Anyway, I had rebuilt
> > > classlib several times with H5756 onboard, run the AUTH tests and
> > > can't reproduce the linkage error you mentioned. I had either running
> > > incremental rebuild or full clean-rebuild, no failure. Makefiles are
> > > already modified in the patch, so the patch remain the same.
> > >
> > > I'm afraid the problem is in your environment, would you please
> > > rebuild from scratch? If the issue is still reproduced, I need more
> > > info on the failure.
> > >
> > > Thanks,
> > > Aleksey.
> > >
> > > On Fri, Apr 18, 2008 at 7:51 AM, Tony Wu <wu...@gmail.com> wrote:
> > > > Hi, Aleksey
> > > > just did a quick look at 5756, seems there will be some
> > > > unsatisfiedlink error in auth and security module because the ois.c
> > > > has been removed. would you please rebuild the native with your
> > > > patch and verify if I'm correct. And please don't forget to modify
> > > > the makefile of linux accordingly. I'll be offline for several
> > > > hours, sorry if I can't reply immediately.
> > > >
> > > >
> > > >
> > > > On 4/17/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > > Hi,
> > > > >
> > > > > There are two additional issues waiting for committers attention:
> > > > > https://issues.apache.org/jira/browse/HARMONY-5756
> > > > > https://issues.apache.org/jira/browse/HARMONY-5718
> > > > >
> > > > > Can anyone review and commit them?
> > > > >
> > > > > Thanks,
> > > > > Aleksey.
> > > > >
> > > > > On Tue, Apr 15, 2008 at 5:27 PM, Aleksey Shipilev
> > > > > <al...@gmail.com> wrote:
> > > > > > Tony,
> > > > > >
> > > > > > I had fixed the issues with JUnit tests, it was my oversight about
> > > > > > handling NoSuchFieldError exceptions.
> > > > > > Now all seem to be OK, LUNI tests were passed.
> > > > > >
> > > > > > Thanks,
> > > > > > Aleksey.
> > > > > >
> > > > > > On Tue, Apr 15, 2008 at 11:14 AM, Aleksey Shipilev
> > > > > >
> > > > > >
> > > > > > <al...@gmail.com> wrote:
> > > > > > > Hm, I didn't expect this, will take a look, thanks.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Apr 15, 2008 at 11:00 AM, Tony Wu <wu...@gmail.com> wro
> > > te:
> > > > > > > > Aleksey,
> > > > > > > > I think keep the benchmark somewhere such as JIRA is also ok.
> > > > > > > >
> > > > > > > > 7 serialization related errors in Collections2Test after applie
> > > d your
> > > > > > > > patch. All of them looked like below.
> > > > > > > >
> > > > > > > > zeroLengthElementArray
> > > > > > > >
> > > > > > > > java.lang.NoSuchFieldError: zeroLengthElementArray at
> > > > > > > > org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(Obj
> > > ectAccessor.java:54)
> > > > > > > > at org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(
> > > ObjectAccessor.java:56)
> > > > > > > > at java.io.ObjectStreamField.getFieldID(ObjectStreamField.java:
> > > 59) at
> > > > > > > > java.io.ObjectInputStream.readFieldValues(ObjectInputStream.jav
> > > a:1133)
> > > > > > > > at java.io.ObjectInputStream.defaultReadObject(ObjectInputStrea
> > > m.java:433)
> > > > > > > > at java.io.ObjectInputStream.readObjectForClass(ObjectInputStre
> > > am.java:1415)
> > > > > > > > at java.io.ObjectInputStream.readHierarchy(ObjectInputStream.ja
> > > va:1322)
> > > > > > > > at java.io.ObjectInputStream.readNewObject(ObjectInputStream.ja
> > > va:1978)
> > > > > > > > at java.io.ObjectInputStream.readNonPrimitiveContent(ObjectInpu
> > > tStream.java:821)
> > > > > > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:
> > > 2130)
> > > > > > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:
> > > 285) at
> > > > > > > > tests.util.SerializationTester.readObject(SerializationTester.j
> > > ava:171)
> > > > > > > > at tests.util.SerializationTester.assertCompabilityEquals(Seria
> > > lizationTester.java:142)
> > > > > > > > at org.apache.harmony.luni.tests.java.util.Collections2Test.tes
> > > t_checkedCollectionSerializationCompatability(Collections2Test.java:418)
> > > > > > > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.
> > > java:25)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote
> > > :
> > > > > > > > > Thanks, Tony!
> > > > > > > > >
> > > > > > > > > There is microbenchmark in [1], is it too big for regression
> > > test?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Aleksey.
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > > > >
> > > > > > > > > On Tue, Apr 15, 2008 at 7:08 AM, Tony Wu <wu...@gmail.com>
> > > wrote:
> > > > > > > > > > Hi, Aleksey
> > > > > > > > > > I'm looking at 5722. I agree with you on leveraging the Ac
> > > cessor but I
> > > > > > > > > > think it would be good if you can post some micro-benchmar
> > > k on this
> > > > > > > > > > JIRA so that we can utilize it as regression test in futur
> > > e.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com>
> > > wrote:
> > > > > > > > > > > Hi all,
> > > > > > > > > > >
> > > > > > > > > > > As you might noticed, there is active work on serializat
> > > ion
> > > > > > > > > > > performance improvements [1]. So far we had committed 4
> > > patches
> > > > > > > > > > > concerning scalability and boosted the performance on mu
> > > lti-threaded
> > > > > > > > > > > serialization benchmarks more than 2x times. And this is
> > > not the end
> > > > > > > > > > > of the journey: more issues coming.
> > > > > > > > > > >
> > > > > > > > > > > Dear committers, can you please review and commit the pa
> > > tches in ready JIRAs?
> > > > > > > > > > > I will be happy if these two committed:
> > > > > > > > > > >
> > > > > > > > > > > a. [classlib][luni][performance] ObjectInputStream/Obje
> > > ctOutputStream
> > > > > > > > > > > can use optimized API for accessing fields - available a
> > > t [2]
> > > > > > > > > > > This issue moves the setField/getField functionality to
> > > ObjectAccessor
> > > > > > > > > > > utility class. This eliminates one serious problem: crea
> > > tion of string
> > > > > > > > > > > during field name lookup on native side. The second adva
> > > ntage is that
> > > > > > > > > > > this solution checks security on accessor creation rathe
> > > r than on
> > > > > > > > > > > every call (like Reflection API does). This improvement
> > > gives another
> > > > > > > > > > > 30-120% boost for serialization workload.
> > > > > > > > > > >
> > > > > > > > > > > I expect more with rewriting these accessors on magics,
> > > thus
> > > > > > > > > > > eliminating JNI overhead and native-side work. Those who
> > > interested in
> > > > > > > > > > > this topic, feel free to join in corresponding JIRA [3].
> > > > > > > > > > >
> > > > > > > > > > > b. [classlib][luni][performance] j.u.IdentityHashMap ar
> > > iphmetic
> > > > > > > > > > > improvements - available at [4]
> > > > > > > > > > > After the moving of ObjectStreamClass cache to ThreadLoc
> > > alCache [5],
> > > > > > > > > > > performance of serialization depends on ThreadLocal perf
> > > ormance and
> > > > > > > > > > > then on IdentityHashMap performance. Simple benchmark sh
> > > ows that
> > > > > > > > > > > ThreadLocal performance is devastating: 50x slower than
> > > Sun 1.6.0_05
> > > > > > > > > > > [6]. This is very first ready patch from that chain of i
> > > ssues. It
> > > > > > > > > > > brings up +300% boost on ThreadLocal benchmark and +10%
> > > boost to
> > > > > > > > > > > serialization benchmark.
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Aleksey.
> > > > > > > > > > >
> > > > > > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > > > > > > [2] https://issues.apache.org/jira/browse/HARMONY-5722 (
> > > ready)
> > > > > > > > > > > [3] https://issues.apache.org/jira/browse/HARMONY-5725
> > > > > > > > > > > [4] https://issues.apache.org/jira/browse/HARMONY-5718 (
> > > ready)
> > > > > > > > > > > [5] https://issues.apache.org/jira/browse/HARMONY-5633
> > > > > > > > > > > [6] https://issues.apache.org/jira/browse/HARMONY-5703
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Tony Wu
> > > > > > > > > > China Software Development Lab, IBM
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > >
> > > > > > > > Tony Wu
> > > > > > > > China Software Development Lab, IBM
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > >
> > > > Tony Wu
> > > > China Software Development Lab, IBM
> > > >
> > >
> >
> >
> >
>
>
> --
> Tony Wu
> China Software Development Lab, IBM
>
Re: [general][performance] Serialization patches need committer attention
Posted by Aleksey Shipilev <al...@gmail.com>.
+1 for moving ObjectAccessor to LUNI.
On Mon, Apr 21, 2008 at 6:32 AM, Tony Wu <wu...@gmail.com> wrote:
> Hi,Mark
> Thanks for pointing out. To remove this dependency, I think we can
> move the ObjectAccessor classes to luni or another separate module.
Thanks,
Aleksey.
Re: [general][performance] Serialization patches need committer attention
Posted by Tony Wu <wu...@gmail.com>.
Hi,Mark
Thanks for pointing out. To remove this dependency, I think we can
move the ObjectAccessor classes to luni or another separate module.
On 4/18/08, Mark Hindess <ma...@googlemail.com> wrote:
>
> Tony, Aleksey,
>
> This patch works for me on linux from a fresh checkout. So I suspect
> Tony has a local problem too.
>
> One thing I am cautious about is that this patch (and the earlier patch
> committed as part of HARMONY-5722) add a dependency from misc.jar to
> luni.jar that was not there before. This is not a problem in itself but
> I think we should discuss such changes on the list before making them.
>
> In this case it probably isn't a big problem since the misc module is
> fairly small and none of the misc dependencies are new to the luni
> module.
>
> Incidentally, isn't the org.apache.harmony.awt.nativebridge package only
> required by the misc module for testing? Shouldn't the MANIFEST reflect
> this?
>
> Regards,
> Mark.
>
> On 18 April 2008 at 10:26, "Aleksey Shipilev" <al...@gmail.com>
> wrote:
> > Tony,
> >
> > Hm... I had run all JUnit tests before attaching the patch to JIRA,
> > no crashes due to linkage errors were occurred. Anyway, I had rebuilt
> > classlib several times with H5756 onboard, run the AUTH tests and
> > can't reproduce the linkage error you mentioned. I had either running
> > incremental rebuild or full clean-rebuild, no failure. Makefiles are
> > already modified in the patch, so the patch remain the same.
> >
> > I'm afraid the problem is in your environment, would you please
> > rebuild from scratch? If the issue is still reproduced, I need more
> > info on the failure.
> >
> > Thanks,
> > Aleksey.
> >
> > On Fri, Apr 18, 2008 at 7:51 AM, Tony Wu <wu...@gmail.com> wrote:
> > > Hi, Aleksey
> > > just did a quick look at 5756, seems there will be some
> > > unsatisfiedlink error in auth and security module because the ois.c
> > > has been removed. would you please rebuild the native with your
> > > patch and verify if I'm correct. And please don't forget to modify
> > > the makefile of linux accordingly. I'll be offline for several
> > > hours, sorry if I can't reply immediately.
> > >
> > >
> > >
> > > On 4/17/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > Hi,
> > > >
> > > > There are two additional issues waiting for committers attention:
> > > > https://issues.apache.org/jira/browse/HARMONY-5756
> > > > https://issues.apache.org/jira/browse/HARMONY-5718
> > > >
> > > > Can anyone review and commit them?
> > > >
> > > > Thanks,
> > > > Aleksey.
> > > >
> > > > On Tue, Apr 15, 2008 at 5:27 PM, Aleksey Shipilev
> > > > <al...@gmail.com> wrote:
> > > > > Tony,
> > > > >
> > > > > I had fixed the issues with JUnit tests, it was my oversight about
> > > > > handling NoSuchFieldError exceptions.
> > > > > Now all seem to be OK, LUNI tests were passed.
> > > > >
> > > > > Thanks,
> > > > > Aleksey.
> > > > >
> > > > > On Tue, Apr 15, 2008 at 11:14 AM, Aleksey Shipilev
> > > > >
> > > > >
> > > > > <al...@gmail.com> wrote:
> > > > > > Hm, I didn't expect this, will take a look, thanks.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 15, 2008 at 11:00 AM, Tony Wu <wu...@gmail.com> wro
> > te:
> > > > > > > Aleksey,
> > > > > > > I think keep the benchmark somewhere such as JIRA is also ok.
> > > > > > >
> > > > > > > 7 serialization related errors in Collections2Test after applie
> > d your
> > > > > > > patch. All of them looked like below.
> > > > > > >
> > > > > > > zeroLengthElementArray
> > > > > > >
> > > > > > > java.lang.NoSuchFieldError: zeroLengthElementArray at
> > > > > > > org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(Obj
> > ectAccessor.java:54)
> > > > > > > at org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(
> > ObjectAccessor.java:56)
> > > > > > > at java.io.ObjectStreamField.getFieldID(ObjectStreamField.java:
> > 59) at
> > > > > > > java.io.ObjectInputStream.readFieldValues(ObjectInputStream.jav
> > a:1133)
> > > > > > > at java.io.ObjectInputStream.defaultReadObject(ObjectInputStrea
> > m.java:433)
> > > > > > > at java.io.ObjectInputStream.readObjectForClass(ObjectInputStre
> > am.java:1415)
> > > > > > > at java.io.ObjectInputStream.readHierarchy(ObjectInputStream.ja
> > va:1322)
> > > > > > > at java.io.ObjectInputStream.readNewObject(ObjectInputStream.ja
> > va:1978)
> > > > > > > at java.io.ObjectInputStream.readNonPrimitiveContent(ObjectInpu
> > tStream.java:821)
> > > > > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:
> > 2130)
> > > > > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:
> > 285) at
> > > > > > > tests.util.SerializationTester.readObject(SerializationTester.j
> > ava:171)
> > > > > > > at tests.util.SerializationTester.assertCompabilityEquals(Seria
> > lizationTester.java:142)
> > > > > > > at org.apache.harmony.luni.tests.java.util.Collections2Test.tes
> > t_checkedCollectionSerializationCompatability(Collections2Test.java:418)
> > > > > > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.
> > java:25)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote
> > :
> > > > > > > > Thanks, Tony!
> > > > > > > >
> > > > > > > > There is microbenchmark in [1], is it too big for regression
> > test?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Aleksey.
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > > >
> > > > > > > > On Tue, Apr 15, 2008 at 7:08 AM, Tony Wu <wu...@gmail.com>
> > wrote:
> > > > > > > > > Hi, Aleksey
> > > > > > > > > I'm looking at 5722. I agree with you on leveraging the Ac
> > cessor but I
> > > > > > > > > think it would be good if you can post some micro-benchmar
> > k on this
> > > > > > > > > JIRA so that we can utilize it as regression test in futur
> > e.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com>
> > wrote:
> > > > > > > > > > Hi all,
> > > > > > > > > >
> > > > > > > > > > As you might noticed, there is active work on serializat
> > ion
> > > > > > > > > > performance improvements [1]. So far we had committed 4
> > patches
> > > > > > > > > > concerning scalability and boosted the performance on mu
> > lti-threaded
> > > > > > > > > > serialization benchmarks more than 2x times. And this is
> > not the end
> > > > > > > > > > of the journey: more issues coming.
> > > > > > > > > >
> > > > > > > > > > Dear committers, can you please review and commit the pa
> > tches in ready JIRAs?
> > > > > > > > > > I will be happy if these two committed:
> > > > > > > > > >
> > > > > > > > > > a. [classlib][luni][performance] ObjectInputStream/Obje
> > ctOutputStream
> > > > > > > > > > can use optimized API for accessing fields - available a
> > t [2]
> > > > > > > > > > This issue moves the setField/getField functionality to
> > ObjectAccessor
> > > > > > > > > > utility class. This eliminates one serious problem: crea
> > tion of string
> > > > > > > > > > during field name lookup on native side. The second adva
> > ntage is that
> > > > > > > > > > this solution checks security on accessor creation rathe
> > r than on
> > > > > > > > > > every call (like Reflection API does). This improvement
> > gives another
> > > > > > > > > > 30-120% boost for serialization workload.
> > > > > > > > > >
> > > > > > > > > > I expect more with rewriting these accessors on magics,
> > thus
> > > > > > > > > > eliminating JNI overhead and native-side work. Those who
> > interested in
> > > > > > > > > > this topic, feel free to join in corresponding JIRA [3].
> > > > > > > > > >
> > > > > > > > > > b. [classlib][luni][performance] j.u.IdentityHashMap ar
> > iphmetic
> > > > > > > > > > improvements - available at [4]
> > > > > > > > > > After the moving of ObjectStreamClass cache to ThreadLoc
> > alCache [5],
> > > > > > > > > > performance of serialization depends on ThreadLocal perf
> > ormance and
> > > > > > > > > > then on IdentityHashMap performance. Simple benchmark sh
> > ows that
> > > > > > > > > > ThreadLocal performance is devastating: 50x slower than
> > Sun 1.6.0_05
> > > > > > > > > > [6]. This is very first ready patch from that chain of i
> > ssues. It
> > > > > > > > > > brings up +300% boost on ThreadLocal benchmark and +10%
> > boost to
> > > > > > > > > > serialization benchmark.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Aleksey.
> > > > > > > > > >
> > > > > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > > > > > [2] https://issues.apache.org/jira/browse/HARMONY-5722 (
> > ready)
> > > > > > > > > > [3] https://issues.apache.org/jira/browse/HARMONY-5725
> > > > > > > > > > [4] https://issues.apache.org/jira/browse/HARMONY-5718 (
> > ready)
> > > > > > > > > > [5] https://issues.apache.org/jira/browse/HARMONY-5633
> > > > > > > > > > [6] https://issues.apache.org/jira/browse/HARMONY-5703
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Tony Wu
> > > > > > > > > China Software Development Lab, IBM
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > >
> > > > > > > Tony Wu
> > > > > > > China Software Development Lab, IBM
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > >
> > > Tony Wu
> > > China Software Development Lab, IBM
> > >
> >
>
>
>
--
Tony Wu
China Software Development Lab, IBM
Re: [general][performance] Serialization patches need committer attention
Posted by Sergey Salishev <se...@gmail.com>.
Mark,
You are correct about dependency to nativebridge. The misc module itself is
self sufficient, only the test depends on nativebridge. To my surprise the
StringAccessor test is the only test present in misc module. So probably the
best solution is to move the test to awt module and remove the dependency at
all. Other solution is rewriting the test using vmmagic Address instead of
nativebridge.
Thanks.
Sergey.
On Fri, Apr 18, 2008 at 5:01 PM, Mark Hindess <ma...@googlemail.com>
wrote:
>
> Tony, Aleksey,
>
> This patch works for me on linux from a fresh checkout. So I suspect
> Tony has a local problem too.
>
> One thing I am cautious about is that this patch (and the earlier patch
> committed as part of HARMONY-5722) add a dependency from misc.jar to
> luni.jar that was not there before. This is not a problem in itself but
> I think we should discuss such changes on the list before making them.
>
> In this case it probably isn't a big problem since the misc module is
> fairly small and none of the misc dependencies are new to the luni
> module.
>
> Incidentally, isn't the org.apache.harmony.awt.nativebridge package only
> required by the misc module for testing? Shouldn't the MANIFEST reflect
> this?
>
> Regards,
> Mark.
>
> On 18 April 2008 at 10:26, "Aleksey Shipilev" <al...@gmail.com>
> wrote:
> > Tony,
> >
> > Hm... I had run all JUnit tests before attaching the patch to JIRA,
> > no crashes due to linkage errors were occurred. Anyway, I had rebuilt
> > classlib several times with H5756 onboard, run the AUTH tests and
> > can't reproduce the linkage error you mentioned. I had either running
> > incremental rebuild or full clean-rebuild, no failure. Makefiles are
> > already modified in the patch, so the patch remain the same.
> >
> > I'm afraid the problem is in your environment, would you please
> > rebuild from scratch? If the issue is still reproduced, I need more
> > info on the failure.
> >
> > Thanks,
> > Aleksey.
> >
> > On Fri, Apr 18, 2008 at 7:51 AM, Tony Wu <wu...@gmail.com> wrote:
> > > Hi, Aleksey
> > > just did a quick look at 5756, seems there will be some
> > > unsatisfiedlink error in auth and security module because the ois.c
> > > has been removed. would you please rebuild the native with your
> > > patch and verify if I'm correct. And please don't forget to modify
> > > the makefile of linux accordingly. I'll be offline for several
> > > hours, sorry if I can't reply immediately.
> > >
> > >
> > >
> > > On 4/17/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > Hi,
> > > >
> > > > There are two additional issues waiting for committers attention:
> > > > https://issues.apache.org/jira/browse/HARMONY-5756
> > > > https://issues.apache.org/jira/browse/HARMONY-5718
> > > >
> > > > Can anyone review and commit them?
> > > >
> > > > Thanks,
> > > > Aleksey.
> > > >
> > > > On Tue, Apr 15, 2008 at 5:27 PM, Aleksey Shipilev
> > > > <al...@gmail.com> wrote:
> > > > > Tony,
> > > > >
> > > > > I had fixed the issues with JUnit tests, it was my oversight
> about
> > > > > handling NoSuchFieldError exceptions.
> > > > > Now all seem to be OK, LUNI tests were passed.
> > > > >
> > > > > Thanks,
> > > > > Aleksey.
> > > > >
> > > > > On Tue, Apr 15, 2008 at 11:14 AM, Aleksey Shipilev
> > > > >
> > > > >
> > > > > <al...@gmail.com> wrote:
> > > > > > Hm, I didn't expect this, will take a look, thanks.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Apr 15, 2008 at 11:00 AM, Tony Wu <wu...@gmail.com>
> wro
> > te:
> > > > > > > Aleksey,
> > > > > > > I think keep the benchmark somewhere such as JIRA is also
> ok.
> > > > > > >
> > > > > > > 7 serialization related errors in Collections2Test after
> applie
> > d your
> > > > > > > patch. All of them looked like below.
> > > > > > >
> > > > > > > zeroLengthElementArray
> > > > > > >
> > > > > > > java.lang.NoSuchFieldError: zeroLengthElementArray at
> > > > > > >
> org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(Obj
> > ectAccessor.java:54)
> > > > > > > at
> org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(
> > ObjectAccessor.java:56)
> > > > > > > at
> java.io.ObjectStreamField.getFieldID(ObjectStreamField.java:
> > 59) at
> > > > > > >
> java.io.ObjectInputStream.readFieldValues(ObjectInputStream.jav
> > a:1133)
> > > > > > > at
> java.io.ObjectInputStream.defaultReadObject(ObjectInputStrea
> > m.java:433)
> > > > > > > at
> java.io.ObjectInputStream.readObjectForClass(ObjectInputStre
> > am.java:1415)
> > > > > > > at
> java.io.ObjectInputStream.readHierarchy(ObjectInputStream.ja
> > va:1322)
> > > > > > > at
> java.io.ObjectInputStream.readNewObject(ObjectInputStream.ja
> > va:1978)
> > > > > > > at
> java.io.ObjectInputStream.readNonPrimitiveContent(ObjectInpu
> > tStream.java:821)
> > > > > > > at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:
> > 2130)
> > > > > > > at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:
> > 285) at
> > > > > > >
> tests.util.SerializationTester.readObject(SerializationTester.j
> > ava:171)
> > > > > > > at
> tests.util.SerializationTester.assertCompabilityEquals(Seria
> > lizationTester.java:142)
> > > > > > > at
> org.apache.harmony.luni.tests.java.util.Collections2Test.tes
> > t_checkedCollectionSerializationCompatability(Collections2Test.java:418)
> > > > > > > at
> java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.
> > java:25)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com>
> wrote
> > :
> > > > > > > > Thanks, Tony!
> > > > > > > >
> > > > > > > > There is microbenchmark in [1], is it too big for
> regression
> > test?
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Aleksey.
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > > >
> > > > > > > > On Tue, Apr 15, 2008 at 7:08 AM, Tony Wu <
> wuyuehao@gmail.com>
> > wrote:
> > > > > > > > > Hi, Aleksey
> > > > > > > > > I'm looking at 5722. I agree with you on leveraging
> the Ac
> > cessor but I
> > > > > > > > > think it would be good if you can post some
> micro-benchmar
> > k on this
> > > > > > > > > JIRA so that we can utilize it as regression test in
> futur
> > e.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 4/15/08, Aleksey Shipilev <
> aleksey.shipilev@gmail.com>
> > wrote:
> > > > > > > > > > Hi all,
> > > > > > > > > >
> > > > > > > > > > As you might noticed, there is active work on
> serializat
> > ion
> > > > > > > > > > performance improvements [1]. So far we had
> committed 4
> > patches
> > > > > > > > > > concerning scalability and boosted the performance
> on mu
> > lti-threaded
> > > > > > > > > > serialization benchmarks more than 2x times. And
> this is
> > not the end
> > > > > > > > > > of the journey: more issues coming.
> > > > > > > > > >
> > > > > > > > > > Dear committers, can you please review and commit
> the pa
> > tches in ready JIRAs?
> > > > > > > > > > I will be happy if these two committed:
> > > > > > > > > >
> > > > > > > > > > a. [classlib][luni][performance]
> ObjectInputStream/Obje
> > ctOutputStream
> > > > > > > > > > can use optimized API for accessing fields -
> available a
> > t [2]
> > > > > > > > > > This issue moves the setField/getField
> functionality to
> > ObjectAccessor
> > > > > > > > > > utility class. This eliminates one serious problem:
> crea
> > tion of string
> > > > > > > > > > during field name lookup on native side. The second
> adva
> > ntage is that
> > > > > > > > > > this solution checks security on accessor creation
> rathe
> > r than on
> > > > > > > > > > every call (like Reflection API does). This
> improvement
> > gives another
> > > > > > > > > > 30-120% boost for serialization workload.
> > > > > > > > > >
> > > > > > > > > > I expect more with rewriting these accessors on
> magics,
> > thus
> > > > > > > > > > eliminating JNI overhead and native-side work.
> Those who
> > interested in
> > > > > > > > > > this topic, feel free to join in corresponding JIRA
> [3].
> > > > > > > > > >
> > > > > > > > > > b. [classlib][luni][performance]
> j.u.IdentityHashMap ar
> > iphmetic
> > > > > > > > > > improvements - available at [4]
> > > > > > > > > > After the moving of ObjectStreamClass cache to
> ThreadLoc
> > alCache [5],
> > > > > > > > > > performance of serialization depends on ThreadLocal
> perf
> > ormance and
> > > > > > > > > > then on IdentityHashMap performance. Simple
> benchmark sh
> > ows that
> > > > > > > > > > ThreadLocal performance is devastating: 50x slower
> than
> > Sun 1.6.0_05
> > > > > > > > > > [6]. This is very first ready patch from that chain
> of i
> > ssues. It
> > > > > > > > > > brings up +300% boost on ThreadLocal benchmark and
> +10%
> > boost to
> > > > > > > > > > serialization benchmark.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Aleksey.
> > > > > > > > > >
> > > > > > > > > > [1]
> https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > > > > > [2]
> https://issues.apache.org/jira/browse/HARMONY-5722 (
> > ready)
> > > > > > > > > > [3]
> https://issues.apache.org/jira/browse/HARMONY-5725
> > > > > > > > > > [4]
> https://issues.apache.org/jira/browse/HARMONY-5718 (
> > ready)
> > > > > > > > > > [5]
> https://issues.apache.org/jira/browse/HARMONY-5633
> > > > > > > > > > [6]
> https://issues.apache.org/jira/browse/HARMONY-5703
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Tony Wu
> > > > > > > > > China Software Development Lab, IBM
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > >
> > > > > > > Tony Wu
> > > > > > > China Software Development Lab, IBM
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > >
> > > Tony Wu
> > > China Software Development Lab, IBM
> > >
> >
>
>
>
Re: [general][performance] Serialization patches need committer
attention
Posted by Mark Hindess <ma...@googlemail.com>.
Tony, Aleksey,
This patch works for me on linux from a fresh checkout. So I suspect
Tony has a local problem too.
One thing I am cautious about is that this patch (and the earlier patch
committed as part of HARMONY-5722) add a dependency from misc.jar to
luni.jar that was not there before. This is not a problem in itself but
I think we should discuss such changes on the list before making them.
In this case it probably isn't a big problem since the misc module is
fairly small and none of the misc dependencies are new to the luni
module.
Incidentally, isn't the org.apache.harmony.awt.nativebridge package only
required by the misc module for testing? Shouldn't the MANIFEST reflect
this?
Regards,
Mark.
On 18 April 2008 at 10:26, "Aleksey Shipilev" <al...@gmail.com>
wrote:
> Tony,
>
> Hm... I had run all JUnit tests before attaching the patch to JIRA,
> no crashes due to linkage errors were occurred. Anyway, I had rebuilt
> classlib several times with H5756 onboard, run the AUTH tests and
> can't reproduce the linkage error you mentioned. I had either running
> incremental rebuild or full clean-rebuild, no failure. Makefiles are
> already modified in the patch, so the patch remain the same.
>
> I'm afraid the problem is in your environment, would you please
> rebuild from scratch? If the issue is still reproduced, I need more
> info on the failure.
>
> Thanks,
> Aleksey.
>
> On Fri, Apr 18, 2008 at 7:51 AM, Tony Wu <wu...@gmail.com> wrote:
> > Hi, Aleksey
> > just did a quick look at 5756, seems there will be some
> > unsatisfiedlink error in auth and security module because the ois.c
> > has been removed. would you please rebuild the native with your
> > patch and verify if I'm correct. And please don't forget to modify
> > the makefile of linux accordingly. I'll be offline for several
> > hours, sorry if I can't reply immediately.
> >
> >
> >
> > On 4/17/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > Hi,
> > >
> > > There are two additional issues waiting for committers attention:
> > > https://issues.apache.org/jira/browse/HARMONY-5756
> > > https://issues.apache.org/jira/browse/HARMONY-5718
> > >
> > > Can anyone review and commit them?
> > >
> > > Thanks,
> > > Aleksey.
> > >
> > > On Tue, Apr 15, 2008 at 5:27 PM, Aleksey Shipilev
> > > <al...@gmail.com> wrote:
> > > > Tony,
> > > >
> > > > I had fixed the issues with JUnit tests, it was my oversight about
> > > > handling NoSuchFieldError exceptions.
> > > > Now all seem to be OK, LUNI tests were passed.
> > > >
> > > > Thanks,
> > > > Aleksey.
> > > >
> > > > On Tue, Apr 15, 2008 at 11:14 AM, Aleksey Shipilev
> > > >
> > > >
> > > > <al...@gmail.com> wrote:
> > > > > Hm, I didn't expect this, will take a look, thanks.
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Apr 15, 2008 at 11:00 AM, Tony Wu <wu...@gmail.com> wro
> te:
> > > > > > Aleksey,
> > > > > > I think keep the benchmark somewhere such as JIRA is also ok.
> > > > > >
> > > > > > 7 serialization related errors in Collections2Test after applie
> d your
> > > > > > patch. All of them looked like below.
> > > > > >
> > > > > > zeroLengthElementArray
> > > > > >
> > > > > > java.lang.NoSuchFieldError: zeroLengthElementArray at
> > > > > > org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(Obj
> ectAccessor.java:54)
> > > > > > at org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(
> ObjectAccessor.java:56)
> > > > > > at java.io.ObjectStreamField.getFieldID(ObjectStreamField.java:
> 59) at
> > > > > > java.io.ObjectInputStream.readFieldValues(ObjectInputStream.jav
> a:1133)
> > > > > > at java.io.ObjectInputStream.defaultReadObject(ObjectInputStrea
> m.java:433)
> > > > > > at java.io.ObjectInputStream.readObjectForClass(ObjectInputStre
> am.java:1415)
> > > > > > at java.io.ObjectInputStream.readHierarchy(ObjectInputStream.ja
> va:1322)
> > > > > > at java.io.ObjectInputStream.readNewObject(ObjectInputStream.ja
> va:1978)
> > > > > > at java.io.ObjectInputStream.readNonPrimitiveContent(ObjectInpu
> tStream.java:821)
> > > > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:
> 2130)
> > > > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:
> 285) at
> > > > > > tests.util.SerializationTester.readObject(SerializationTester.j
> ava:171)
> > > > > > at tests.util.SerializationTester.assertCompabilityEquals(Seria
> lizationTester.java:142)
> > > > > > at org.apache.harmony.luni.tests.java.util.Collections2Test.tes
> t_checkedCollectionSerializationCompatability(Collections2Test.java:418)
> > > > > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.
> java:25)
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote
> :
> > > > > > > Thanks, Tony!
> > > > > > >
> > > > > > > There is microbenchmark in [1], is it too big for regression
> test?
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Aleksey.
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > >
> > > > > > > On Tue, Apr 15, 2008 at 7:08 AM, Tony Wu <wu...@gmail.com>
> wrote:
> > > > > > > > Hi, Aleksey
> > > > > > > > I'm looking at 5722. I agree with you on leveraging the Ac
> cessor but I
> > > > > > > > think it would be good if you can post some micro-benchmar
> k on this
> > > > > > > > JIRA so that we can utilize it as regression test in futur
> e.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com>
> wrote:
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > As you might noticed, there is active work on serializat
> ion
> > > > > > > > > performance improvements [1]. So far we had committed 4
> patches
> > > > > > > > > concerning scalability and boosted the performance on mu
> lti-threaded
> > > > > > > > > serialization benchmarks more than 2x times. And this is
> not the end
> > > > > > > > > of the journey: more issues coming.
> > > > > > > > >
> > > > > > > > > Dear committers, can you please review and commit the pa
> tches in ready JIRAs?
> > > > > > > > > I will be happy if these two committed:
> > > > > > > > >
> > > > > > > > > a. [classlib][luni][performance] ObjectInputStream/Obje
> ctOutputStream
> > > > > > > > > can use optimized API for accessing fields - available a
> t [2]
> > > > > > > > > This issue moves the setField/getField functionality to
> ObjectAccessor
> > > > > > > > > utility class. This eliminates one serious problem: crea
> tion of string
> > > > > > > > > during field name lookup on native side. The second adva
> ntage is that
> > > > > > > > > this solution checks security on accessor creation rathe
> r than on
> > > > > > > > > every call (like Reflection API does). This improvement
> gives another
> > > > > > > > > 30-120% boost for serialization workload.
> > > > > > > > >
> > > > > > > > > I expect more with rewriting these accessors on magics,
> thus
> > > > > > > > > eliminating JNI overhead and native-side work. Those who
> interested in
> > > > > > > > > this topic, feel free to join in corresponding JIRA [3].
> > > > > > > > >
> > > > > > > > > b. [classlib][luni][performance] j.u.IdentityHashMap ar
> iphmetic
> > > > > > > > > improvements - available at [4]
> > > > > > > > > After the moving of ObjectStreamClass cache to ThreadLoc
> alCache [5],
> > > > > > > > > performance of serialization depends on ThreadLocal perf
> ormance and
> > > > > > > > > then on IdentityHashMap performance. Simple benchmark sh
> ows that
> > > > > > > > > ThreadLocal performance is devastating: 50x slower than
> Sun 1.6.0_05
> > > > > > > > > [6]. This is very first ready patch from that chain of i
> ssues. It
> > > > > > > > > brings up +300% boost on ThreadLocal benchmark and +10%
> boost to
> > > > > > > > > serialization benchmark.
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Aleksey.
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > > > > [2] https://issues.apache.org/jira/browse/HARMONY-5722 (
> ready)
> > > > > > > > > [3] https://issues.apache.org/jira/browse/HARMONY-5725
> > > > > > > > > [4] https://issues.apache.org/jira/browse/HARMONY-5718 (
> ready)
> > > > > > > > > [5] https://issues.apache.org/jira/browse/HARMONY-5633
> > > > > > > > > [6] https://issues.apache.org/jira/browse/HARMONY-5703
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Tony Wu
> > > > > > > > China Software Development Lab, IBM
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > >
> > > > > > Tony Wu
> > > > > > China Software Development Lab, IBM
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> >
> >
> > Tony Wu
> > China Software Development Lab, IBM
> >
>
Re: [general][performance] Serialization patches need committer attention
Posted by Aleksey Shipilev <al...@gmail.com>.
Tony,
Hm... I had run all JUnit tests before attaching the patch to JIRA, no
crashes due to linkage errors were occurred. Anyway, I had rebuilt
classlib several times with H5756 onboard, run the AUTH tests and
can't reproduce the linkage error you mentioned. I had either running
incremental rebuild or full clean-rebuild, no failure. Makefiles are
already modified in the patch, so the patch remain the same.
I'm afraid the problem is in your environment, would you please
rebuild from scratch? If the issue is still reproduced, I need more
info on the failure.
Thanks,
Aleksey.
On Fri, Apr 18, 2008 at 7:51 AM, Tony Wu <wu...@gmail.com> wrote:
> Hi, Aleksey
> just did a quick look at 5756, seems there will be some
> unsatisfiedlink error in auth and security module because the ois.c
> has been removed. would you please rebuild the native with your patch
> and verify if I'm correct. And please don't forget to modify the
> makefile of linux accordingly. I'll be offline for several hours,
> sorry if I can't reply immediately.
>
>
>
> On 4/17/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > Hi,
> >
> > There are two additional issues waiting for committers attention:
> > https://issues.apache.org/jira/browse/HARMONY-5756
> > https://issues.apache.org/jira/browse/HARMONY-5718
> >
> > Can anyone review and commit them?
> >
> > Thanks,
> > Aleksey.
> >
> > On Tue, Apr 15, 2008 at 5:27 PM, Aleksey Shipilev
> > <al...@gmail.com> wrote:
> > > Tony,
> > >
> > > I had fixed the issues with JUnit tests, it was my oversight about
> > > handling NoSuchFieldError exceptions.
> > > Now all seem to be OK, LUNI tests were passed.
> > >
> > > Thanks,
> > > Aleksey.
> > >
> > > On Tue, Apr 15, 2008 at 11:14 AM, Aleksey Shipilev
> > >
> > >
> > > <al...@gmail.com> wrote:
> > > > Hm, I didn't expect this, will take a look, thanks.
> > > >
> > > >
> > > >
> > > > On Tue, Apr 15, 2008 at 11:00 AM, Tony Wu <wu...@gmail.com> wrote:
> > > > > Aleksey,
> > > > > I think keep the benchmark somewhere such as JIRA is also ok.
> > > > >
> > > > > 7 serialization related errors in Collections2Test after applied your
> > > > > patch. All of them looked like below.
> > > > >
> > > > > zeroLengthElementArray
> > > > >
> > > > > java.lang.NoSuchFieldError: zeroLengthElementArray at
> > > > > org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:54)
> > > > > at org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:56)
> > > > > at java.io.ObjectStreamField.getFieldID(ObjectStreamField.java:59) at
> > > > > java.io.ObjectInputStream.readFieldValues(ObjectInputStream.java:1133)
> > > > > at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:433)
> > > > > at java.io.ObjectInputStream.readObjectForClass(ObjectInputStream.java:1415)
> > > > > at java.io.ObjectInputStream.readHierarchy(ObjectInputStream.java:1322)
> > > > > at java.io.ObjectInputStream.readNewObject(ObjectInputStream.java:1978)
> > > > > at java.io.ObjectInputStream.readNonPrimitiveContent(ObjectInputStream.java:821)
> > > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:2130)
> > > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:285) at
> > > > > tests.util.SerializationTester.readObject(SerializationTester.java:171)
> > > > > at tests.util.SerializationTester.assertCompabilityEquals(SerializationTester.java:142)
> > > > > at org.apache.harmony.luni.tests.java.util.Collections2Test.test_checkedCollectionSerializationCompatability(Collections2Test.java:418)
> > > > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > > > Thanks, Tony!
> > > > > >
> > > > > > There is microbenchmark in [1], is it too big for regression test?
> > > > > >
> > > > > > Thanks,
> > > > > > Aleksey.
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > >
> > > > > > On Tue, Apr 15, 2008 at 7:08 AM, Tony Wu <wu...@gmail.com> wrote:
> > > > > > > Hi, Aleksey
> > > > > > > I'm looking at 5722. I agree with you on leveraging the Accessor but I
> > > > > > > think it would be good if you can post some micro-benchmark on this
> > > > > > > JIRA so that we can utilize it as regression test in future.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > As you might noticed, there is active work on serialization
> > > > > > > > performance improvements [1]. So far we had committed 4 patches
> > > > > > > > concerning scalability and boosted the performance on multi-threaded
> > > > > > > > serialization benchmarks more than 2x times. And this is not the end
> > > > > > > > of the journey: more issues coming.
> > > > > > > >
> > > > > > > > Dear committers, can you please review and commit the patches in ready JIRAs?
> > > > > > > > I will be happy if these two committed:
> > > > > > > >
> > > > > > > > a. [classlib][luni][performance] ObjectInputStream/ObjectOutputStream
> > > > > > > > can use optimized API for accessing fields - available at [2]
> > > > > > > > This issue moves the setField/getField functionality to ObjectAccessor
> > > > > > > > utility class. This eliminates one serious problem: creation of string
> > > > > > > > during field name lookup on native side. The second advantage is that
> > > > > > > > this solution checks security on accessor creation rather than on
> > > > > > > > every call (like Reflection API does). This improvement gives another
> > > > > > > > 30-120% boost for serialization workload.
> > > > > > > >
> > > > > > > > I expect more with rewriting these accessors on magics, thus
> > > > > > > > eliminating JNI overhead and native-side work. Those who interested in
> > > > > > > > this topic, feel free to join in corresponding JIRA [3].
> > > > > > > >
> > > > > > > > b. [classlib][luni][performance] j.u.IdentityHashMap ariphmetic
> > > > > > > > improvements - available at [4]
> > > > > > > > After the moving of ObjectStreamClass cache to ThreadLocalCache [5],
> > > > > > > > performance of serialization depends on ThreadLocal performance and
> > > > > > > > then on IdentityHashMap performance. Simple benchmark shows that
> > > > > > > > ThreadLocal performance is devastating: 50x slower than Sun 1.6.0_05
> > > > > > > > [6]. This is very first ready patch from that chain of issues. It
> > > > > > > > brings up +300% boost on ThreadLocal benchmark and +10% boost to
> > > > > > > > serialization benchmark.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Aleksey.
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > > > [2] https://issues.apache.org/jira/browse/HARMONY-5722 (ready)
> > > > > > > > [3] https://issues.apache.org/jira/browse/HARMONY-5725
> > > > > > > > [4] https://issues.apache.org/jira/browse/HARMONY-5718 (ready)
> > > > > > > > [5] https://issues.apache.org/jira/browse/HARMONY-5633
> > > > > > > > [6] https://issues.apache.org/jira/browse/HARMONY-5703
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Tony Wu
> > > > > > > China Software Development Lab, IBM
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > >
> > > > > Tony Wu
> > > > > China Software Development Lab, IBM
> > > > >
> > > >
> > >
> >
>
>
> --
>
>
> Tony Wu
> China Software Development Lab, IBM
>
Re: [general][performance] Serialization patches need committer attention
Posted by Tony Wu <wu...@gmail.com>.
Hi, Aleksey
just did a quick look at 5756, seems there will be some
unsatisfiedlink error in auth and security module because the ois.c
has been removed. would you please rebuild the native with your patch
and verify if I'm correct. And please don't forget to modify the
makefile of linux accordingly. I'll be offline for several hours,
sorry if I can't reply immediately.
On 4/17/08, Aleksey Shipilev <al...@gmail.com> wrote:
> Hi,
>
> There are two additional issues waiting for committers attention:
> https://issues.apache.org/jira/browse/HARMONY-5756
> https://issues.apache.org/jira/browse/HARMONY-5718
>
> Can anyone review and commit them?
>
> Thanks,
> Aleksey.
>
> On Tue, Apr 15, 2008 at 5:27 PM, Aleksey Shipilev
> <al...@gmail.com> wrote:
> > Tony,
> >
> > I had fixed the issues with JUnit tests, it was my oversight about
> > handling NoSuchFieldError exceptions.
> > Now all seem to be OK, LUNI tests were passed.
> >
> > Thanks,
> > Aleksey.
> >
> > On Tue, Apr 15, 2008 at 11:14 AM, Aleksey Shipilev
> >
> >
> > <al...@gmail.com> wrote:
> > > Hm, I didn't expect this, will take a look, thanks.
> > >
> > >
> > >
> > > On Tue, Apr 15, 2008 at 11:00 AM, Tony Wu <wu...@gmail.com> wrote:
> > > > Aleksey,
> > > > I think keep the benchmark somewhere such as JIRA is also ok.
> > > >
> > > > 7 serialization related errors in Collections2Test after applied your
> > > > patch. All of them looked like below.
> > > >
> > > > zeroLengthElementArray
> > > >
> > > > java.lang.NoSuchFieldError: zeroLengthElementArray at
> > > > org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:54)
> > > > at org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:56)
> > > > at java.io.ObjectStreamField.getFieldID(ObjectStreamField.java:59) at
> > > > java.io.ObjectInputStream.readFieldValues(ObjectInputStream.java:1133)
> > > > at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:433)
> > > > at java.io.ObjectInputStream.readObjectForClass(ObjectInputStream.java:1415)
> > > > at java.io.ObjectInputStream.readHierarchy(ObjectInputStream.java:1322)
> > > > at java.io.ObjectInputStream.readNewObject(ObjectInputStream.java:1978)
> > > > at java.io.ObjectInputStream.readNonPrimitiveContent(ObjectInputStream.java:821)
> > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:2130)
> > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:285) at
> > > > tests.util.SerializationTester.readObject(SerializationTester.java:171)
> > > > at tests.util.SerializationTester.assertCompabilityEquals(SerializationTester.java:142)
> > > > at org.apache.harmony.luni.tests.java.util.Collections2Test.test_checkedCollectionSerializationCompatability(Collections2Test.java:418)
> > > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
> > > >
> > > >
> > > >
> > > >
> > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > > Thanks, Tony!
> > > > >
> > > > > There is microbenchmark in [1], is it too big for regression test?
> > > > >
> > > > > Thanks,
> > > > > Aleksey.
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > >
> > > > > On Tue, Apr 15, 2008 at 7:08 AM, Tony Wu <wu...@gmail.com> wrote:
> > > > > > Hi, Aleksey
> > > > > > I'm looking at 5722. I agree with you on leveraging the Accessor but I
> > > > > > think it would be good if you can post some micro-benchmark on this
> > > > > > JIRA so that we can utilize it as regression test in future.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > As you might noticed, there is active work on serialization
> > > > > > > performance improvements [1]. So far we had committed 4 patches
> > > > > > > concerning scalability and boosted the performance on multi-threaded
> > > > > > > serialization benchmarks more than 2x times. And this is not the end
> > > > > > > of the journey: more issues coming.
> > > > > > >
> > > > > > > Dear committers, can you please review and commit the patches in ready JIRAs?
> > > > > > > I will be happy if these two committed:
> > > > > > >
> > > > > > > a. [classlib][luni][performance] ObjectInputStream/ObjectOutputStream
> > > > > > > can use optimized API for accessing fields - available at [2]
> > > > > > > This issue moves the setField/getField functionality to ObjectAccessor
> > > > > > > utility class. This eliminates one serious problem: creation of string
> > > > > > > during field name lookup on native side. The second advantage is that
> > > > > > > this solution checks security on accessor creation rather than on
> > > > > > > every call (like Reflection API does). This improvement gives another
> > > > > > > 30-120% boost for serialization workload.
> > > > > > >
> > > > > > > I expect more with rewriting these accessors on magics, thus
> > > > > > > eliminating JNI overhead and native-side work. Those who interested in
> > > > > > > this topic, feel free to join in corresponding JIRA [3].
> > > > > > >
> > > > > > > b. [classlib][luni][performance] j.u.IdentityHashMap ariphmetic
> > > > > > > improvements - available at [4]
> > > > > > > After the moving of ObjectStreamClass cache to ThreadLocalCache [5],
> > > > > > > performance of serialization depends on ThreadLocal performance and
> > > > > > > then on IdentityHashMap performance. Simple benchmark shows that
> > > > > > > ThreadLocal performance is devastating: 50x slower than Sun 1.6.0_05
> > > > > > > [6]. This is very first ready patch from that chain of issues. It
> > > > > > > brings up +300% boost on ThreadLocal benchmark and +10% boost to
> > > > > > > serialization benchmark.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Aleksey.
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > > [2] https://issues.apache.org/jira/browse/HARMONY-5722 (ready)
> > > > > > > [3] https://issues.apache.org/jira/browse/HARMONY-5725
> > > > > > > [4] https://issues.apache.org/jira/browse/HARMONY-5718 (ready)
> > > > > > > [5] https://issues.apache.org/jira/browse/HARMONY-5633
> > > > > > > [6] https://issues.apache.org/jira/browse/HARMONY-5703
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Tony Wu
> > > > > > China Software Development Lab, IBM
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > >
> > > > Tony Wu
> > > > China Software Development Lab, IBM
> > > >
> > >
> >
>
--
Tony Wu
China Software Development Lab, IBM
Re: [general][performance] Serialization patches need committer attention
Posted by Aleksey Shipilev <al...@gmail.com>.
Hi,
There are two additional issues waiting for committers attention:
https://issues.apache.org/jira/browse/HARMONY-5756
https://issues.apache.org/jira/browse/HARMONY-5718
Can anyone review and commit them?
Thanks,
Aleksey.
On Tue, Apr 15, 2008 at 5:27 PM, Aleksey Shipilev
<al...@gmail.com> wrote:
> Tony,
>
> I had fixed the issues with JUnit tests, it was my oversight about
> handling NoSuchFieldError exceptions.
> Now all seem to be OK, LUNI tests were passed.
>
> Thanks,
> Aleksey.
>
> On Tue, Apr 15, 2008 at 11:14 AM, Aleksey Shipilev
>
>
> <al...@gmail.com> wrote:
> > Hm, I didn't expect this, will take a look, thanks.
> >
> >
> >
> > On Tue, Apr 15, 2008 at 11:00 AM, Tony Wu <wu...@gmail.com> wrote:
> > > Aleksey,
> > > I think keep the benchmark somewhere such as JIRA is also ok.
> > >
> > > 7 serialization related errors in Collections2Test after applied your
> > > patch. All of them looked like below.
> > >
> > > zeroLengthElementArray
> > >
> > > java.lang.NoSuchFieldError: zeroLengthElementArray at
> > > org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:54)
> > > at org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:56)
> > > at java.io.ObjectStreamField.getFieldID(ObjectStreamField.java:59) at
> > > java.io.ObjectInputStream.readFieldValues(ObjectInputStream.java:1133)
> > > at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:433)
> > > at java.io.ObjectInputStream.readObjectForClass(ObjectInputStream.java:1415)
> > > at java.io.ObjectInputStream.readHierarchy(ObjectInputStream.java:1322)
> > > at java.io.ObjectInputStream.readNewObject(ObjectInputStream.java:1978)
> > > at java.io.ObjectInputStream.readNonPrimitiveContent(ObjectInputStream.java:821)
> > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:2130)
> > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:285) at
> > > tests.util.SerializationTester.readObject(SerializationTester.java:171)
> > > at tests.util.SerializationTester.assertCompabilityEquals(SerializationTester.java:142)
> > > at org.apache.harmony.luni.tests.java.util.Collections2Test.test_checkedCollectionSerializationCompatability(Collections2Test.java:418)
> > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
> > >
> > >
> > >
> > >
> > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > Thanks, Tony!
> > > >
> > > > There is microbenchmark in [1], is it too big for regression test?
> > > >
> > > > Thanks,
> > > > Aleksey.
> > > >
> > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > >
> > > > On Tue, Apr 15, 2008 at 7:08 AM, Tony Wu <wu...@gmail.com> wrote:
> > > > > Hi, Aleksey
> > > > > I'm looking at 5722. I agree with you on leveraging the Accessor but I
> > > > > think it would be good if you can post some micro-benchmark on this
> > > > > JIRA so that we can utilize it as regression test in future.
> > > > >
> > > > >
> > > > >
> > > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > As you might noticed, there is active work on serialization
> > > > > > performance improvements [1]. So far we had committed 4 patches
> > > > > > concerning scalability and boosted the performance on multi-threaded
> > > > > > serialization benchmarks more than 2x times. And this is not the end
> > > > > > of the journey: more issues coming.
> > > > > >
> > > > > > Dear committers, can you please review and commit the patches in ready JIRAs?
> > > > > > I will be happy if these two committed:
> > > > > >
> > > > > > a. [classlib][luni][performance] ObjectInputStream/ObjectOutputStream
> > > > > > can use optimized API for accessing fields - available at [2]
> > > > > > This issue moves the setField/getField functionality to ObjectAccessor
> > > > > > utility class. This eliminates one serious problem: creation of string
> > > > > > during field name lookup on native side. The second advantage is that
> > > > > > this solution checks security on accessor creation rather than on
> > > > > > every call (like Reflection API does). This improvement gives another
> > > > > > 30-120% boost for serialization workload.
> > > > > >
> > > > > > I expect more with rewriting these accessors on magics, thus
> > > > > > eliminating JNI overhead and native-side work. Those who interested in
> > > > > > this topic, feel free to join in corresponding JIRA [3].
> > > > > >
> > > > > > b. [classlib][luni][performance] j.u.IdentityHashMap ariphmetic
> > > > > > improvements - available at [4]
> > > > > > After the moving of ObjectStreamClass cache to ThreadLocalCache [5],
> > > > > > performance of serialization depends on ThreadLocal performance and
> > > > > > then on IdentityHashMap performance. Simple benchmark shows that
> > > > > > ThreadLocal performance is devastating: 50x slower than Sun 1.6.0_05
> > > > > > [6]. This is very first ready patch from that chain of issues. It
> > > > > > brings up +300% boost on ThreadLocal benchmark and +10% boost to
> > > > > > serialization benchmark.
> > > > > >
> > > > > > Thanks,
> > > > > > Aleksey.
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > > [2] https://issues.apache.org/jira/browse/HARMONY-5722 (ready)
> > > > > > [3] https://issues.apache.org/jira/browse/HARMONY-5725
> > > > > > [4] https://issues.apache.org/jira/browse/HARMONY-5718 (ready)
> > > > > > [5] https://issues.apache.org/jira/browse/HARMONY-5633
> > > > > > [6] https://issues.apache.org/jira/browse/HARMONY-5703
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Tony Wu
> > > > > China Software Development Lab, IBM
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > >
> > > Tony Wu
> > > China Software Development Lab, IBM
> > >
> >
>
Re: [general][performance] Serialization patches need committer attention
Posted by Aleksey Shipilev <al...@gmail.com>.
Tony,
I had fixed the issues with JUnit tests, it was my oversight about
handling NoSuchFieldError exceptions.
Now all seem to be OK, LUNI tests were passed.
Thanks,
Aleksey.
On Tue, Apr 15, 2008 at 11:14 AM, Aleksey Shipilev
<al...@gmail.com> wrote:
> Hm, I didn't expect this, will take a look, thanks.
>
>
>
> On Tue, Apr 15, 2008 at 11:00 AM, Tony Wu <wu...@gmail.com> wrote:
> > Aleksey,
> > I think keep the benchmark somewhere such as JIRA is also ok.
> >
> > 7 serialization related errors in Collections2Test after applied your
> > patch. All of them looked like below.
> >
> > zeroLengthElementArray
> >
> > java.lang.NoSuchFieldError: zeroLengthElementArray at
> > org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:54)
> > at org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:56)
> > at java.io.ObjectStreamField.getFieldID(ObjectStreamField.java:59) at
> > java.io.ObjectInputStream.readFieldValues(ObjectInputStream.java:1133)
> > at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:433)
> > at java.io.ObjectInputStream.readObjectForClass(ObjectInputStream.java:1415)
> > at java.io.ObjectInputStream.readHierarchy(ObjectInputStream.java:1322)
> > at java.io.ObjectInputStream.readNewObject(ObjectInputStream.java:1978)
> > at java.io.ObjectInputStream.readNonPrimitiveContent(ObjectInputStream.java:821)
> > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:2130)
> > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:285) at
> > tests.util.SerializationTester.readObject(SerializationTester.java:171)
> > at tests.util.SerializationTester.assertCompabilityEquals(SerializationTester.java:142)
> > at org.apache.harmony.luni.tests.java.util.Collections2Test.test_checkedCollectionSerializationCompatability(Collections2Test.java:418)
> > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
> >
> >
> >
> >
> > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > Thanks, Tony!
> > >
> > > There is microbenchmark in [1], is it too big for regression test?
> > >
> > > Thanks,
> > > Aleksey.
> > >
> > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > >
> > > On Tue, Apr 15, 2008 at 7:08 AM, Tony Wu <wu...@gmail.com> wrote:
> > > > Hi, Aleksey
> > > > I'm looking at 5722. I agree with you on leveraging the Accessor but I
> > > > think it would be good if you can post some micro-benchmark on this
> > > > JIRA so that we can utilize it as regression test in future.
> > > >
> > > >
> > > >
> > > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > > Hi all,
> > > > >
> > > > > As you might noticed, there is active work on serialization
> > > > > performance improvements [1]. So far we had committed 4 patches
> > > > > concerning scalability and boosted the performance on multi-threaded
> > > > > serialization benchmarks more than 2x times. And this is not the end
> > > > > of the journey: more issues coming.
> > > > >
> > > > > Dear committers, can you please review and commit the patches in ready JIRAs?
> > > > > I will be happy if these two committed:
> > > > >
> > > > > a. [classlib][luni][performance] ObjectInputStream/ObjectOutputStream
> > > > > can use optimized API for accessing fields - available at [2]
> > > > > This issue moves the setField/getField functionality to ObjectAccessor
> > > > > utility class. This eliminates one serious problem: creation of string
> > > > > during field name lookup on native side. The second advantage is that
> > > > > this solution checks security on accessor creation rather than on
> > > > > every call (like Reflection API does). This improvement gives another
> > > > > 30-120% boost for serialization workload.
> > > > >
> > > > > I expect more with rewriting these accessors on magics, thus
> > > > > eliminating JNI overhead and native-side work. Those who interested in
> > > > > this topic, feel free to join in corresponding JIRA [3].
> > > > >
> > > > > b. [classlib][luni][performance] j.u.IdentityHashMap ariphmetic
> > > > > improvements - available at [4]
> > > > > After the moving of ObjectStreamClass cache to ThreadLocalCache [5],
> > > > > performance of serialization depends on ThreadLocal performance and
> > > > > then on IdentityHashMap performance. Simple benchmark shows that
> > > > > ThreadLocal performance is devastating: 50x slower than Sun 1.6.0_05
> > > > > [6]. This is very first ready patch from that chain of issues. It
> > > > > brings up +300% boost on ThreadLocal benchmark and +10% boost to
> > > > > serialization benchmark.
> > > > >
> > > > > Thanks,
> > > > > Aleksey.
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > > [2] https://issues.apache.org/jira/browse/HARMONY-5722 (ready)
> > > > > [3] https://issues.apache.org/jira/browse/HARMONY-5725
> > > > > [4] https://issues.apache.org/jira/browse/HARMONY-5718 (ready)
> > > > > [5] https://issues.apache.org/jira/browse/HARMONY-5633
> > > > > [6] https://issues.apache.org/jira/browse/HARMONY-5703
> > > > >
> > > >
> > > >
> > > > --
> > > > Tony Wu
> > > > China Software Development Lab, IBM
> > > >
> > >
> >
> >
> > --
> >
> >
> > Tony Wu
> > China Software Development Lab, IBM
> >
>
Re: [general][performance] Serialization patches need committer attention
Posted by Aleksey Shipilev <al...@gmail.com>.
Hm, I didn't expect this, will take a look, thanks.
On Tue, Apr 15, 2008 at 11:00 AM, Tony Wu <wu...@gmail.com> wrote:
> Aleksey,
> I think keep the benchmark somewhere such as JIRA is also ok.
>
> 7 serialization related errors in Collections2Test after applied your
> patch. All of them looked like below.
>
> zeroLengthElementArray
>
> java.lang.NoSuchFieldError: zeroLengthElementArray at
> org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:54)
> at org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:56)
> at java.io.ObjectStreamField.getFieldID(ObjectStreamField.java:59) at
> java.io.ObjectInputStream.readFieldValues(ObjectInputStream.java:1133)
> at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:433)
> at java.io.ObjectInputStream.readObjectForClass(ObjectInputStream.java:1415)
> at java.io.ObjectInputStream.readHierarchy(ObjectInputStream.java:1322)
> at java.io.ObjectInputStream.readNewObject(ObjectInputStream.java:1978)
> at java.io.ObjectInputStream.readNonPrimitiveContent(ObjectInputStream.java:821)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:2130)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:285) at
> tests.util.SerializationTester.readObject(SerializationTester.java:171)
> at tests.util.SerializationTester.assertCompabilityEquals(SerializationTester.java:142)
> at org.apache.harmony.luni.tests.java.util.Collections2Test.test_checkedCollectionSerializationCompatability(Collections2Test.java:418)
> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
>
>
>
>
> On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > Thanks, Tony!
> >
> > There is microbenchmark in [1], is it too big for regression test?
> >
> > Thanks,
> > Aleksey.
> >
> > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> >
> > On Tue, Apr 15, 2008 at 7:08 AM, Tony Wu <wu...@gmail.com> wrote:
> > > Hi, Aleksey
> > > I'm looking at 5722. I agree with you on leveraging the Accessor but I
> > > think it would be good if you can post some micro-benchmark on this
> > > JIRA so that we can utilize it as regression test in future.
> > >
> > >
> > >
> > > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > > Hi all,
> > > >
> > > > As you might noticed, there is active work on serialization
> > > > performance improvements [1]. So far we had committed 4 patches
> > > > concerning scalability and boosted the performance on multi-threaded
> > > > serialization benchmarks more than 2x times. And this is not the end
> > > > of the journey: more issues coming.
> > > >
> > > > Dear committers, can you please review and commit the patches in ready JIRAs?
> > > > I will be happy if these two committed:
> > > >
> > > > a. [classlib][luni][performance] ObjectInputStream/ObjectOutputStream
> > > > can use optimized API for accessing fields - available at [2]
> > > > This issue moves the setField/getField functionality to ObjectAccessor
> > > > utility class. This eliminates one serious problem: creation of string
> > > > during field name lookup on native side. The second advantage is that
> > > > this solution checks security on accessor creation rather than on
> > > > every call (like Reflection API does). This improvement gives another
> > > > 30-120% boost for serialization workload.
> > > >
> > > > I expect more with rewriting these accessors on magics, thus
> > > > eliminating JNI overhead and native-side work. Those who interested in
> > > > this topic, feel free to join in corresponding JIRA [3].
> > > >
> > > > b. [classlib][luni][performance] j.u.IdentityHashMap ariphmetic
> > > > improvements - available at [4]
> > > > After the moving of ObjectStreamClass cache to ThreadLocalCache [5],
> > > > performance of serialization depends on ThreadLocal performance and
> > > > then on IdentityHashMap performance. Simple benchmark shows that
> > > > ThreadLocal performance is devastating: 50x slower than Sun 1.6.0_05
> > > > [6]. This is very first ready patch from that chain of issues. It
> > > > brings up +300% boost on ThreadLocal benchmark and +10% boost to
> > > > serialization benchmark.
> > > >
> > > > Thanks,
> > > > Aleksey.
> > > >
> > > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > > [2] https://issues.apache.org/jira/browse/HARMONY-5722 (ready)
> > > > [3] https://issues.apache.org/jira/browse/HARMONY-5725
> > > > [4] https://issues.apache.org/jira/browse/HARMONY-5718 (ready)
> > > > [5] https://issues.apache.org/jira/browse/HARMONY-5633
> > > > [6] https://issues.apache.org/jira/browse/HARMONY-5703
> > > >
> > >
> > >
> > > --
> > > Tony Wu
> > > China Software Development Lab, IBM
> > >
> >
>
>
> --
>
>
> Tony Wu
> China Software Development Lab, IBM
>
Re: [general][performance] Serialization patches need committer attention
Posted by Tony Wu <wu...@gmail.com>.
Aleksey,
I think keep the benchmark somewhere such as JIRA is also ok.
7 serialization related errors in Collections2Test after applied your
patch. All of them looked like below.
zeroLengthElementArray
java.lang.NoSuchFieldError: zeroLengthElementArray at
org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:54)
at org.apache.harmony.misc.accessors.ObjectAccessor.getFieldID(ObjectAccessor.java:56)
at java.io.ObjectStreamField.getFieldID(ObjectStreamField.java:59) at
java.io.ObjectInputStream.readFieldValues(ObjectInputStream.java:1133)
at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:433)
at java.io.ObjectInputStream.readObjectForClass(ObjectInputStream.java:1415)
at java.io.ObjectInputStream.readHierarchy(ObjectInputStream.java:1322)
at java.io.ObjectInputStream.readNewObject(ObjectInputStream.java:1978)
at java.io.ObjectInputStream.readNonPrimitiveContent(ObjectInputStream.java:821)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:2130)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:285) at
tests.util.SerializationTester.readObject(SerializationTester.java:171)
at tests.util.SerializationTester.assertCompabilityEquals(SerializationTester.java:142)
at org.apache.harmony.luni.tests.java.util.Collections2Test.test_checkedCollectionSerializationCompatability(Collections2Test.java:418)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> Thanks, Tony!
>
> There is microbenchmark in [1], is it too big for regression test?
>
> Thanks,
> Aleksey.
>
> [1] https://issues.apache.org/jira/browse/HARMONY-5632
>
> On Tue, Apr 15, 2008 at 7:08 AM, Tony Wu <wu...@gmail.com> wrote:
> > Hi, Aleksey
> > I'm looking at 5722. I agree with you on leveraging the Accessor but I
> > think it would be good if you can post some micro-benchmark on this
> > JIRA so that we can utilize it as regression test in future.
> >
> >
> >
> > On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > > Hi all,
> > >
> > > As you might noticed, there is active work on serialization
> > > performance improvements [1]. So far we had committed 4 patches
> > > concerning scalability and boosted the performance on multi-threaded
> > > serialization benchmarks more than 2x times. And this is not the end
> > > of the journey: more issues coming.
> > >
> > > Dear committers, can you please review and commit the patches in ready JIRAs?
> > > I will be happy if these two committed:
> > >
> > > a. [classlib][luni][performance] ObjectInputStream/ObjectOutputStream
> > > can use optimized API for accessing fields - available at [2]
> > > This issue moves the setField/getField functionality to ObjectAccessor
> > > utility class. This eliminates one serious problem: creation of string
> > > during field name lookup on native side. The second advantage is that
> > > this solution checks security on accessor creation rather than on
> > > every call (like Reflection API does). This improvement gives another
> > > 30-120% boost for serialization workload.
> > >
> > > I expect more with rewriting these accessors on magics, thus
> > > eliminating JNI overhead and native-side work. Those who interested in
> > > this topic, feel free to join in corresponding JIRA [3].
> > >
> > > b. [classlib][luni][performance] j.u.IdentityHashMap ariphmetic
> > > improvements - available at [4]
> > > After the moving of ObjectStreamClass cache to ThreadLocalCache [5],
> > > performance of serialization depends on ThreadLocal performance and
> > > then on IdentityHashMap performance. Simple benchmark shows that
> > > ThreadLocal performance is devastating: 50x slower than Sun 1.6.0_05
> > > [6]. This is very first ready patch from that chain of issues. It
> > > brings up +300% boost on ThreadLocal benchmark and +10% boost to
> > > serialization benchmark.
> > >
> > > Thanks,
> > > Aleksey.
> > >
> > > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > > [2] https://issues.apache.org/jira/browse/HARMONY-5722 (ready)
> > > [3] https://issues.apache.org/jira/browse/HARMONY-5725
> > > [4] https://issues.apache.org/jira/browse/HARMONY-5718 (ready)
> > > [5] https://issues.apache.org/jira/browse/HARMONY-5633
> > > [6] https://issues.apache.org/jira/browse/HARMONY-5703
> > >
> >
> >
> > --
> > Tony Wu
> > China Software Development Lab, IBM
> >
>
--
Tony Wu
China Software Development Lab, IBM
Re: [general][performance] Serialization patches need committer attention
Posted by Aleksey Shipilev <al...@gmail.com>.
Thanks, Tony!
There is microbenchmark in [1], is it too big for regression test?
Thanks,
Aleksey.
[1] https://issues.apache.org/jira/browse/HARMONY-5632
On Tue, Apr 15, 2008 at 7:08 AM, Tony Wu <wu...@gmail.com> wrote:
> Hi, Aleksey
> I'm looking at 5722. I agree with you on leveraging the Accessor but I
> think it would be good if you can post some micro-benchmark on this
> JIRA so that we can utilize it as regression test in future.
>
>
>
> On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> > Hi all,
> >
> > As you might noticed, there is active work on serialization
> > performance improvements [1]. So far we had committed 4 patches
> > concerning scalability and boosted the performance on multi-threaded
> > serialization benchmarks more than 2x times. And this is not the end
> > of the journey: more issues coming.
> >
> > Dear committers, can you please review and commit the patches in ready JIRAs?
> > I will be happy if these two committed:
> >
> > a. [classlib][luni][performance] ObjectInputStream/ObjectOutputStream
> > can use optimized API for accessing fields - available at [2]
> > This issue moves the setField/getField functionality to ObjectAccessor
> > utility class. This eliminates one serious problem: creation of string
> > during field name lookup on native side. The second advantage is that
> > this solution checks security on accessor creation rather than on
> > every call (like Reflection API does). This improvement gives another
> > 30-120% boost for serialization workload.
> >
> > I expect more with rewriting these accessors on magics, thus
> > eliminating JNI overhead and native-side work. Those who interested in
> > this topic, feel free to join in corresponding JIRA [3].
> >
> > b. [classlib][luni][performance] j.u.IdentityHashMap ariphmetic
> > improvements - available at [4]
> > After the moving of ObjectStreamClass cache to ThreadLocalCache [5],
> > performance of serialization depends on ThreadLocal performance and
> > then on IdentityHashMap performance. Simple benchmark shows that
> > ThreadLocal performance is devastating: 50x slower than Sun 1.6.0_05
> > [6]. This is very first ready patch from that chain of issues. It
> > brings up +300% boost on ThreadLocal benchmark and +10% boost to
> > serialization benchmark.
> >
> > Thanks,
> > Aleksey.
> >
> > [1] https://issues.apache.org/jira/browse/HARMONY-5632
> > [2] https://issues.apache.org/jira/browse/HARMONY-5722 (ready)
> > [3] https://issues.apache.org/jira/browse/HARMONY-5725
> > [4] https://issues.apache.org/jira/browse/HARMONY-5718 (ready)
> > [5] https://issues.apache.org/jira/browse/HARMONY-5633
> > [6] https://issues.apache.org/jira/browse/HARMONY-5703
> >
>
>
> --
> Tony Wu
> China Software Development Lab, IBM
>
Re: [general][performance] Serialization patches need committer attention
Posted by Tony Wu <wu...@gmail.com>.
Hi, Aleksey
I'm looking at 5722. I agree with you on leveraging the Accessor but I
think it would be good if you can post some micro-benchmark on this
JIRA so that we can utilize it as regression test in future.
On 4/15/08, Aleksey Shipilev <al...@gmail.com> wrote:
> Hi all,
>
> As you might noticed, there is active work on serialization
> performance improvements [1]. So far we had committed 4 patches
> concerning scalability and boosted the performance on multi-threaded
> serialization benchmarks more than 2x times. And this is not the end
> of the journey: more issues coming.
>
> Dear committers, can you please review and commit the patches in ready JIRAs?
> I will be happy if these two committed:
>
> a. [classlib][luni][performance] ObjectInputStream/ObjectOutputStream
> can use optimized API for accessing fields - available at [2]
> This issue moves the setField/getField functionality to ObjectAccessor
> utility class. This eliminates one serious problem: creation of string
> during field name lookup on native side. The second advantage is that
> this solution checks security on accessor creation rather than on
> every call (like Reflection API does). This improvement gives another
> 30-120% boost for serialization workload.
>
> I expect more with rewriting these accessors on magics, thus
> eliminating JNI overhead and native-side work. Those who interested in
> this topic, feel free to join in corresponding JIRA [3].
>
> b. [classlib][luni][performance] j.u.IdentityHashMap ariphmetic
> improvements - available at [4]
> After the moving of ObjectStreamClass cache to ThreadLocalCache [5],
> performance of serialization depends on ThreadLocal performance and
> then on IdentityHashMap performance. Simple benchmark shows that
> ThreadLocal performance is devastating: 50x slower than Sun 1.6.0_05
> [6]. This is very first ready patch from that chain of issues. It
> brings up +300% boost on ThreadLocal benchmark and +10% boost to
> serialization benchmark.
>
> Thanks,
> Aleksey.
>
> [1] https://issues.apache.org/jira/browse/HARMONY-5632
> [2] https://issues.apache.org/jira/browse/HARMONY-5722 (ready)
> [3] https://issues.apache.org/jira/browse/HARMONY-5725
> [4] https://issues.apache.org/jira/browse/HARMONY-5718 (ready)
> [5] https://issues.apache.org/jira/browse/HARMONY-5633
> [6] https://issues.apache.org/jira/browse/HARMONY-5703
>
--
Tony Wu
China Software Development Lab, IBM