Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of sergey.i.salishev@gmail.com
 designates 74.125.46.154 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=lFKENb0JN2E6Zu1RzUPuKnfyvpe6EkyRt1610782wEh4aPmrhDKwmnZ39XfpvAsFVYzG8668RxlHx25R+hY9aQIdJrdZ1otvriv3JjK05lUy6gjBFN8RXb+3fhxHqqjuSe5ZCm34VhSGcSoAoPJmxM/uWr+cVRU08xEBMN9dYm8=
Message-ID: <728dc7fa0804181015n1939ad66vda8436c7c41f5e2d@mail.gmail.com>
Date: Fri, 18 Apr 2008 21:15:31 +0400
From: "Sergey Salishev" <sergey.i.salishev@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [general][performance] Serialization patches need committer
 attention
In-Reply-To: <200804181302.m3ID2AsI014857@d06av01.portsmouth.uk.ibm.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_2710_6485412.1208538931648"
References: <4bebff790804141504y79468a5dl64a4dfcbd3aa6e1d@mail.gmail.com>
	 <211709bc0804142008l3dc18c27xcf3e4b442e6708d3@mail.gmail.com>
	 <4bebff790804142234q53a85c52t88df8627d4fbb13b@mail.gmail.com>
	 <211709bc0804150000k73e258d2r5fcb770d0e74c37e@mail.gmail.com>
	 <4bebff790804150014r70591552wf88c247d06101acb@mail.gmail.com>
	 <4bebff790804150627l2320469bica3160270bbda507@mail.gmail.com>
	 <4bebff790804170702o7124f25fxf179c9c989ed3bbb@mail.gmail.com>
	 <211709bc0804172051p7afbfe48u748a5d53036e2010@mail.gmail.com>
	 <4bebff790804172326y63715e6dle615a1f86cceaaeb@mail.gmail.com>
	 <200804181302.m3ID2AsI014857@d06av01.portsmouth.uk.ibm.com>

------=_Part_2710_6485412.1208538931648
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 <mark.hindess@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" <aleksey.shipilev@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 <wuyuehao@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 <aleksey.shipilev@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
> > >  > <aleksey.shipilev@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
> > >  > >
> > >  > >
> > >  > > <aleksey.shipilev@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 <wuyuehao@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 <aleksey.shipilev@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
> > >
> >
>
>
>

------=_Part_2710_6485412.1208538931648--