Return-Path: Delivered-To: apmail-harmony-commits-archive@www.apache.org Received: (qmail 92708 invoked from network); 1 Mar 2008 10:47:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 1 Mar 2008 10:47:53 -0000 Received: (qmail 2051 invoked by uid 500); 1 Mar 2008 10:47:48 -0000 Delivered-To: apmail-harmony-commits-archive@harmony.apache.org Received: (qmail 2017 invoked by uid 500); 1 Mar 2008 10:47:48 -0000 Mailing-List: contact commits-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 commits@harmony.apache.org Received: (qmail 2000 invoked by uid 99); 1 Mar 2008 10:47:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 01 Mar 2008 02:47:47 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 01 Mar 2008 10:47:21 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 5C0B4234C077 for ; Sat, 1 Mar 2008 02:46:51 -0800 (PST) Message-ID: <2021419393.1204368411375.JavaMail.jira@brutus> Date: Sat, 1 Mar 2008 02:46:51 -0800 (PST) From: "Egor Pasko (JIRA)" To: commits@harmony.apache.org Subject: [jira] Updated: (HARMONY-5356) [drlvm][startup][performance] Delayed recompilation implementation In-Reply-To: <29040872.1198841263037.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HARMONY-5356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Egor Pasko updated HARMONY-5356: -------------------------------- Description: Now, client JIT chains look like this: chains=chain1,chain2 chain1.jits=JET_CLINIT chain2.jits=JET_DPGO,CD_OPT chain1.filter=+:: chain1.filter=- JET_CLINIT.file=jitrino JET_DPGO.file=jitrino CD_OPT.file=jitrino JET_DPGO.genProfile=EB_PROF EB_PROF.profilerType=EB_PROFILER CD_OPT.useProfile=EB_PROF So, all methods (class initializers) are passing through JET_DPGO with EB_PROF attached and then will be recompiled by CD_OPT. One should note that this will cause concurrency between on-going _recompilation_ and first-time JET compilation. So, if first-time JET compilation speed is important for startup, then we should separate these two processes in time. That is, let's compile all in the bunch with JET and only then start to recompile with OPT. That is, we can either: a. Set the thresholds for EB_PROF such as recompilation would held later b. Introduce new step (e.g. JET_QUICK) which would compile really fast (even without profile) and wait before inducing recompilation. Current architecture of Jitrino requires some profiler to do the notification for traversing the JITs chain, so attached patch introduces dummy DELAY_PROFILER which simply waits desired time. So, we will have: chains=chain1,chain2 chain1.jits=JET_CLINIT chain2.jits=JET_QUICK,JET_DPGO,CD_OPT chain1.filter=+:: chain1.filter=- JET_CLINIT.file=jitrino JET_QUICK.file=jitrino JET_DPGO.file=jitrino CD_OPT.file=jitrino JET_DPGO.genProfile=EB_PROF EB_PROF.profilerType=EB_PROFILER CD_OPT.useProfile=EB_PROF JET_QUICK.genProfile=DL_PROF DL_PROF.profilerType=DL_PROFILER DL_PROF.initialTimeout=0 DL_PROF.delayTimeout=100 was: Now, client JIT chains look like this: chains=chain1,chain2 chain1.jits=JET_CLINIT chain2.jits=JET_DPGO,CD_OPT chain1.filter=+:: chain1.filter=- JET_CLINIT.file=jitrino JET_DPGO.file=jitrino CD_OPT.file=jitrino JET_DPGO.genProfile=EB_PROF EB_PROF.profilerType=EB_PROFILER CD_OPT.useProfile=EB_PROF So, all methods (except constructors) are passing through JET_DPGO with EB_PROF attached and then will be recompiled by CD_OPT. One should note that this will cause concurrency between on-going _recompilation_ and first-time JET compilation. So, if first-time JET compilation speed is important for startup, then we should separate these two processes in time. That is, let's compile all in the bunch with JET and only then start to recompile with OPT. That is, we can either: a. Set the thresholds for EB_PROF such as recompilation would held later b. Introduce new step (e.g. JET_QUICK) which would compile really fast (even without profile) and wait before inducing recompilation. Current architecture of Jitrino requires some profiler to do the notification for traversing the JITs chain, so attached patch introduces dummy DELAY_PROFILER which simply waits desired time. So, we will have: chains=chain1,chain2 chain1.jits=JET_CLINIT chain2.jits=JET_QUICK,JET_DPGO,CD_OPT chain1.filter=+:: chain1.filter=- JET_CLINIT.file=jitrino JET_QUICK.file=jitrino JET_DPGO.file=jitrino CD_OPT.file=jitrino JET_DPGO.genProfile=EB_PROF EB_PROF.profilerType=EB_PROFILER CD_OPT.useProfile=EB_PROF JET_QUICK.genProfile=DL_PROF DL_PROF.profilerType=DL_PROFILER DL_PROF.initialTimeout=0 DL_PROF.delayTimeout=100 > [drlvm][startup][performance] Delayed recompilation implementation > ------------------------------------------------------------------ > > Key: HARMONY-5356 > URL: https://issues.apache.org/jira/browse/HARMONY-5356 > Project: Harmony > Issue Type: Sub-task > Reporter: Aleksey Shipilev > Attachments: vm-delayprofiler-1.patch > > > Now, client JIT chains look like this: > chains=chain1,chain2 > chain1.jits=JET_CLINIT > chain2.jits=JET_DPGO,CD_OPT > chain1.filter=+:: > chain1.filter=- > JET_CLINIT.file=jitrino > JET_DPGO.file=jitrino > CD_OPT.file=jitrino > JET_DPGO.genProfile=EB_PROF > EB_PROF.profilerType=EB_PROFILER > CD_OPT.useProfile=EB_PROF > So, all methods (class initializers) are passing through JET_DPGO with EB_PROF attached and then will be recompiled by CD_OPT. One should note that this will cause concurrency between on-going _recompilation_ and first-time JET compilation. So, if first-time JET compilation speed is important for startup, then we should separate these two processes in time. That is, let's compile all in the bunch with JET and only then start to recompile with OPT. > That is, we can either: > a. Set the thresholds for EB_PROF such as recompilation would held later > b. Introduce new step (e.g. JET_QUICK) which would compile really fast (even without profile) and wait before inducing recompilation. > Current architecture of Jitrino requires some profiler to do the notification for traversing the JITs chain, so attached patch introduces dummy DELAY_PROFILER which simply waits desired time. > So, we will have: > chains=chain1,chain2 > chain1.jits=JET_CLINIT > chain2.jits=JET_QUICK,JET_DPGO,CD_OPT > chain1.filter=+:: > chain1.filter=- > JET_CLINIT.file=jitrino > JET_QUICK.file=jitrino > JET_DPGO.file=jitrino > CD_OPT.file=jitrino > JET_DPGO.genProfile=EB_PROF > EB_PROF.profilerType=EB_PROFILER > CD_OPT.useProfile=EB_PROF > JET_QUICK.genProfile=DL_PROF > DL_PROF.profilerType=DL_PROFILER > DL_PROF.initialTimeout=0 > DL_PROF.delayTimeout=100 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.