Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: DRLVM
    • Labels:
      None
    • Patch Info:
      Patch Available
    • Estimated Complexity:
      Moderate

      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 (except 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

      1. vm-delayprofiler-2.patch
        17 kB
        Aleksey Shipilev
      2. vm-delayprofiler-1.patch
        17 kB
        Aleksey Shipilev

        Activity

        Hide
        Aleksey Shipilev added a comment -

        vm-delayprofiler-2.patch
        Updated for current state of DRLVM trunk.

        Show
        Aleksey Shipilev added a comment - vm-delayprofiler-2.patch Updated for current state of DRLVM trunk.
        Hide
        Egor Pasko added a comment -

        some benchmarks might call hottest methods only twice, i.e. give only one chance to detect a hot method. In these cases making recompilation chain longer will theoretically slow things down

        P.S.: yep, I am a theory lover here

        Show
        Egor Pasko added a comment - some benchmarks might call hottest methods only twice, i.e. give only one chance to detect a hot method. In these cases making recompilation chain longer will theoretically slow things down P.S.: yep, I am a theory lover here
        Hide
        Aleksey Shipilev added a comment -

        Mikhail, please postpone works on this issue. There are degradations on other benchmarks. I will send update later.

        Show
        Aleksey Shipilev added a comment - Mikhail, please postpone works on this issue. There are degradations on other benchmarks. I will send update later.
        Hide
        Aleksey Shipilev added a comment -

        Mikhail, it's used in
        pc = new DelayProfileCollector(this, profilerName, step->jit, initialTimeout, delayTimeout);

        That's the place to optimize. My thought was it works like this: we specify delayTimeout as tick interval, and then making tick-tack with method tables (on current tick all new methods coming to be registered, all previously registered methods are notified). Even though it's not guaranteed each method will be delayed for exact delayTimeout, this approach is simple and solves the problem I described.

        Show
        Aleksey Shipilev added a comment - Mikhail, it's used in pc = new DelayProfileCollector(this, profilerName, step->jit, initialTimeout, delayTimeout); That's the place to optimize. My thought was it works like this: we specify delayTimeout as tick interval, and then making tick-tack with method tables (on current tick all new methods coming to be registered, all previously registered methods are notified). Even though it's not guaranteed each method will be delayed for exact delayTimeout, this approach is simple and solves the problem I described.
        Hide
        Mikhail Fursov added a comment -

        Aleksey,
        is it correct that 'delayTimeout' value is not used at all in profile collector?

        Show
        Mikhail Fursov added a comment - Aleksey, is it correct that 'delayTimeout' value is not used at all in profile collector?
        Hide
        Aleksey Shipilev added a comment -

        Setting JET_DPGO thresholds only:
        a. EIOffice starts up +1.5% faster
        b. Eclipse starts up +5% faster

        Show
        Aleksey Shipilev added a comment - Setting JET_DPGO thresholds only: a. EIOffice starts up +1.5% faster b. Eclipse starts up +5% faster
        Hide
        Aleksey Shipilev added a comment -

        With the attached patch:
        a. EIOffice starts up +4.2% faster
        b. Eclipse starts up +15% faster

        Show
        Aleksey Shipilev added a comment - With the attached patch: a. EIOffice starts up +4.2% faster b. Eclipse starts up +15% faster
        Hide
        Aleksey Shipilev added a comment -

        vm-delayprofiler-1.patch
        The patch for issue.

        Show
        Aleksey Shipilev added a comment - vm-delayprofiler-1.patch The patch for issue.

          People

          • Assignee:
            Xiao-Feng Li
            Reporter:
            Aleksey Shipilev
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development