harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Egor Pasko (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-5356) [drlvm][startup][performance] Delayed recompilation implementation
Date Sat, 01 Mar 2008 10:46:51 GMT

     [ 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=+::<clinit>
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=+::<clinit>
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=+::<clinit>
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=+::<clinit>
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=+::<clinit>
> 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=+::<clinit>
> 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.


Mime
View raw message