Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 42930 invoked from network); 18 Apr 2008 09:58:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Apr 2008 09:58:21 -0000 Received: (qmail 66316 invoked by uid 500); 18 Apr 2008 09:58:22 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 65761 invoked by uid 500); 18 Apr 2008 09:58:21 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 65743 invoked by uid 99); 18 Apr 2008 09:58:21 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Apr 2008 02:58:20 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sean.xx.qiu@gmail.com designates 209.85.142.191 as permitted sender) Received: from [209.85.142.191] (HELO ti-out-0910.google.com) (209.85.142.191) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Apr 2008 09:57:38 +0000 Received: by ti-out-0910.google.com with SMTP id d10so117090tib.18 for ; Fri, 18 Apr 2008 02:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=R5l6brGmiacF97rraL+ysSazEPuIR93ozl1i3o3jYzg=; b=Qp8OZQ+5GAQ/9XMjdPGb1JR/x8FidsDJu7uuJqtV+0qfTjv4sHvK3ZMlslPxwKUvc0JdrgoYTDVxZR2BeAGSQ9qVMnl3ETxO9j4Kla2fv6JFvHOcgInDlKECZHWXlnXeyewXtgCPDNtReJqVA+TMh0gm6vjUV92R8ekjVxEeQAk= 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:content-transfer-encoding:content-disposition:references; b=EcrnSHvFHfZRAVR8XKoi7KPxzNBvAwV/RFXyV/JelkQwA4iRMg2lVmJGn28NZZyczF6SA7P8s7C6YgpWVf2U+CKAFApEulLZvwRJJizGiLYqPcLWzR1ypoO6//LPXGiIr9evZ16Y8cH0oxxT/gNnal6vJe7SuEhJ1r9h/v2gAM4= Received: by 10.110.92.8 with SMTP id p8mr253401tib.24.1208512670325; Fri, 18 Apr 2008 02:57:50 -0700 (PDT) Received: by 10.110.86.9 with HTTP; Fri, 18 Apr 2008 02:57:50 -0700 (PDT) Message-ID: <94d710af0804180257xc470be5r736342f5fc98d168@mail.gmail.com> Date: Fri, 18 Apr 2008 17:57:50 +0800 From: "Sean Qiu" To: dev@harmony.apache.org Subject: Re: [general][repos] Benchmark repository In-Reply-To: <4bebff790804172354n340a79d1g28f5bca11471aae3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4bebff790804150625v76a01165pc2c06cc5226cfcac@mail.gmail.com> <211709bc0804152014j6dd7d8damef7407522a4fea4@mail.gmail.com> <6e47b64f0804152203u237b78c9xe5e423d6eda94324@mail.gmail.com> <6e47b64f0804152357h6b7a4baenb283fd3d130a8fbf@mail.gmail.com> <94d710af0804160909m2f3f9577uccd7f1d27b45214b@mail.gmail.com> <4bebff790804172354n340a79d1g28f5bca11471aae3@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org You can get a brief introduction to BTI from here: http://harmony.apache.org/subcomponents/buildtest/index.html http://svn.apache.org/repos/asf/harmony/enhanced/buildtest/trunk/infra/README.txt You can get a development introduction of BTI from here: http://svn.apache.org/repos/asf/harmony/enhanced/buildtest/trunk/infra/SPEC.txt If you want to know more implementation details about BTI, you can refer to this document: http://svn.apache.org/repos/asf/harmony/enhanced/buildtest/trunk/infra/dev-guide.txt I hope this will be helpful to you. 2008/4/18, Aleksey Shipilev : > So, should I make the benchmark ready for running via BTI? > Are there any guidelines and criteria it should meet? > > Thanks, > > Aleksey. > > > On Wed, Apr 16, 2008 at 8:09 PM, Sean Qiu wrote: > > What about adding a web UI for our BTI? > > I think it is natural since we have a similar one to publish our results. > > > > Just like continuum[1], it is easier to manage. > > Maybe we can get some hint from it. > > > > Anyway, BTI is worthwhile devation. > > > > [1] http://continuum.apache.org/ > > > > > > > > 2008/4/16, Stepan Mishura : > > > On 4/16/08, Alexey Varlamov wrote: > > > > 2008/4/16, Stepan Mishura : > > > > > On 4/16/08, Alexey Varlamov wrote: > > > > > > 2008/4/16, Tony Wu : > > > > > > > Is it possible to integrate into BTI? if not we can consider the enhanced/tools/ > > > > > > > > > > > > There is one already in drlvm trunk, see working_vm/src/test/microbenchmark. > > > > > > There is no infrastructure around, it is mere store holder for now. > > > > > > Feel free to add benches there, they are not intended to be > > > > > > VM-specific. > > > > > > > > > > > > > > > > I would say opposite if they are DRLVM specific then it is OK to put > > > > > them to the folder. Otherwise (i.e. they are not VM-specific) we > > > > > should integrate them to BTI. > > > > > > > > > > Th point is that DRLVM workspace should contain only DRLVM specific > > > > > tests. For example, IMO DRLVM workspace is not the right place for > > > > > EHWA-API scenario. > > > > > > > > This is too radical position IMO. Absolute majority of tests in DRLVM > > > > are functional and not impl-specific, should we move them all to BTI? > > > > > > > > > > Yes, IMHO we should move them to BTI. > > > > > > The point is that any workspace (classlib/drlvm/jdktools) is not a > > > repository for a set of different suites. > > > > > > > Sometimes convenience of using and extending is more important for > > > > success. If we had appropriate infra for benchmarks I wouldn't argue, > > > > but now I'm afraid most contributors would rather leave a bench-case > > > > hanging in JIRA than dare to hack BTI. I'm happy to be proven wrong, > > > > though. > > > > > > > > > > "convenience of using and extending" is questionable for me in this case. > > > Well, yes I agree that from position of a DRLVM developer it is more > > > convenient when EHWA-API scenario is located in DRLVM workspace - no > > > additional efforts are required to run it. But what about classlib > > > developer who wants to run EHWA-API on J9 - she/he needs to checkout > > > DRLVM workspace. Is this convenient and extensible? (Hmm, may be I was > > > wrong when I insisted on integration of LDAP scenario into BTI then > > > into classlibrary ;-)) > > > > > > Seriously, if we think that using BTI is complicated for a developer > > > then we should do our best and make it simpler and more convenient. > > > Otherwise we finish with zoo of different suites/scenarios in several > > > places. > > > > > > Thanks, > > > Stepan. > > > > > > > Regards, > > > > Alexey > > > > > > > > > > Thanks, > > > > > Stepan. > > > > > > > > > > > Re integration to BTI, this would require fair amount of efforts and > > > > > > usage model is not clear to me. > > > > > > > > > > > > > > > > > > > > On 4/15/08, Aleksey Shipilev wrote: > > > > > > > > Hi Tony, all! > > > > > > > > > > > > > > > > Does it make sense to create special place in our repository for > > > > > > > > storing the benchmarks like this one I've used in my performance > > > > > > > > researches on Harmony? It would be great to have them synchronized in > > > > > > > > repos rather than store in JIRA. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Aleksey. > > > > > > > > > > > > > > > > On Tue, Apr 15, 2008 at 11:00 AM, Tony Wu wrote: > > > > > > > > > Aleksey, > > > > > > > > > I think keep the benchmark somewhere such as JIRA is also ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Tony Wu > > > > > > > China Software Development Lab, IBM > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Best Regards > > Sean, Xiao Xia Qiu > > > > > > > > China Software Development Lab, IBM > > > -- Best Regards Sean, Xiao Xia Qiu China Software Development Lab, IBM