<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Sorry, I wasn't very specific.  The 10,000 invocation is the default
    for server VM.  For client, I think it is 1,500 invocations.<br>
    <br>
    I simplified my explanation.  Optimization for server doesn't start
    until 10,000 method invocations or 10,000 loop iterations.  However,
    the optimized code won't be used unless the thread enters the method
    or iteration after the compilation is done.<br>
    <br>
    JRockit JVM never executed bytecode.  When the class was loaded, it
    immediately created native code albeit not fully optimized.  This
    made JRockit startup times much slower than HotSpot.  However,
    JRockit was usually able to get to full speed much faster.  This
    prompted HotSpot to adopted a tiered compilation strategy.  1,000
    invocations was used to avoid the slow startup times yet get to
    native code sooner than waiting until 10,000 invocations.  If
    configurable, you can probably get HotSpot to behave like JRockit by
    setting the first compilation to 0 or 1 invocations.<br>
    <br>
    1,000 and 10,000 seem like arbitrary values with a little bit of
    experience or science behind them.  Sure, anyone could tune these
    values specific for their application to get the optimal start up
    and warm up performance.  But, how can we pick the best value
    averaged for all workloads?  How do we even collect that data?  We
    could run several tests and find the best value averaged for those
    tests, but there will always be a more optimal value for each
    individual application.  It seems this is something best for the
    program writer to tune.<br>
    <div class="moz-cite-prefix"><br>
      <div class="moz-signature"><a
          href="http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds">Nathan
          Reynolds</a> | Architect | 602.333.9091<br>
        <font color="red">Oracle</font> <a
          href="http://psr.us.oracle.com/">PSR Engineering</a> | Server
        Technology<br>
      </div>
      On 2/7/2013 9:08 AM, Gregg Wonderly wrote:<br>
    </div>
    <blockquote class=" cite" id="mid_5113D176_5070309_cytetech_com"
      cite="mid:5113D176.5070309@cytetech.com" type="cite">I've always
      wondered why these kinds of "large" invocation counts are used. 
      In many methods, there will be a single entry in most
      applications, and "loops" inside of that method could be optimized
      much sooner.  In many of my desktop applications, I set the
      invocation count (on the command line) to 100 or even 25, and get
      faster startups, and better performance for the small amount of
      time that I use the apps.  For the client VM, it really seems
      strange to wait so long (1000 invocations), to compile with
      instrumentation.  Then waiting for 10 times that many invocations
      to decide on the final optimizations seems a bit of a stretch.
      <br>
      <br>
      Are there real data values from lots of different users which
      indicate that these "counts" are when people are ready to be more
      productive?  I know that there are probably lots of degenerative
      cases where optimizations will be missed without enough data.  But
      it would seem better to go to native code early, and adapt
      occasionally, rather than wait until you can be sure to be
      perfect.
      <br>
      <br>
      Gregg Wonderly
      <br>
      <br>
      On 2/7/2013 9:49 AM, Nathan Reynolds wrote:
      <br>
      <blockquote class=" cite" id="Cite_0" type="cite">With tiered
        compilation, once a method reaches 1,000 invocations
        <br>
        (configurable?), it is compiled with instrumentation.  Then when
        it reaches
        <br>
        10,000 invocations (configurable), it is fully optimized using
        the
        <br>
        instrumentation profiling data.  For these operations, the JIT
        threads should
        <br>
        run at a higher priority.  However, there are some optimizations
        which are too
        <br>
        heavy to do at a high priority.  These optimizations should be
        done at a low
        <br>
        priority.  Also, methods, which haven't quite reached the 1,000
        invocations but
        <br>
        are being execute, could be compiled with instrumentation at a
        low priority.
        <br>
        <br>
        The low priority work will only be done if the CPU isn't maxed
        out.  If any
        <br>
        other thread needs the CPU, then the low priority compiler
        thread will be
        <br>
        immediately context switched off the core.  So, the low priority
        compilation
        <br>
        will never significantly hurt the performance of the high
        priority threads.  For
        <br>
        some work loads, the low priority threads may never get a chance
        to run. That's
        <br>
        okay because the work isn't that important.
        <br>
        <br>
        Nathan Reynolds
        <a class="moz-txt-link-rfc2396E" href="http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds"><http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds></a>
        |
        <br>
        Architect | 602.333.9091
        <br>
        Oracle PSR Engineering <a class="moz-txt-link-rfc2396E" href="http://psr.us.oracle.com/"><http://psr.us.oracle.com/></a> |
        Server Technology
        <br>
        On 2/7/2013 12:21 AM, Stanimir Simeonoff wrote:
        <br>
        <blockquote class=" cite" id="Cite_1" type="cite">Thread
          priorities are usually NOT applied at all.
          <br>
          For insance:
          <br>
               intx DefaultThreadPriority                     =
          -1              {product}
          <br>
              intx JavaPriority10_To_OSPriority              =
          -1              {product}
          <br>
               intx JavaPriority1_To_OSPriority               =
          -1              {product}
          <br>
               intx JavaPriority2_To_OSPriority               =
          -1              {product}
          <br>
               intx JavaPriority3_To_OSPriority               =
          -1              {product}
          <br>
               intx JavaPriority4_To_OSPriority               =
          -1              {product}
          <br>
               intx JavaPriority5_To_OSPriority               =
          -1              {product}
          <br>
               intx JavaPriority6_To_OSPriority               =
          -1              {product}
          <br>
               intx JavaPriority7_To_OSPriority               =
          -1              {product}
          <br>
               intx JavaPriority8_To_OSPriority               =
          -1              {product}
          <br>
               intx JavaPriority9_To_OSPriority               =
          -1              {product}
          <br>
          <br>
          in other words unless specified :
          -XXJavaPriority10_To_OSPriority=
          <br>
          it won't be mapped.
          <br>
          <br>
          If applied the JVM compiler/GC threads may become starved
          which you don't
          <br>
          want, so they have to work above normal prir (that request
          root privileges).
          <br>
          Alternatively the normal java threads have to run w/ lower
          prir which means
          <br>
          other process will have higher priority - also unpleasant.
          <br>
          <br>
          Stanimir
          <br>
          <br>
          On Thu, Feb 7, 2013 at 5:20 AM, Mohan Radhakrishnan
          <br>
          <<a class="moz-txt-link-abbreviated" href="mailto:radhakrishnan.mohan@gmail.com">radhakrishnan.mohan@gmail.com</a>
          <a class="moz-txt-link-rfc2396E" href="mailto:radhakrishnan.mohan@gmail.com"><mailto:radhakrishnan.mohan@gmail.com></a>> wrote:
          <br>
          <br>
              Hi,
          <br>
                        Can the Thread priority setting in the API still
          be reliably
          <br>
              used uniformly across processors ? There are other
          concurrency patterns in
          <br>
              the API but this setting is still there.
          <br>
          <br>
          <br>
              Thanks,
          <br>
              Mohan
          <br>
          <br>
              _______________________________________________
          <br>
              Concurrency-interest mailing list
          <br>
              <a class="moz-txt-link-abbreviated" href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a>
          <a class="moz-txt-link-rfc2396E" href="mailto:Concurrency-interest@cs.oswego.edu"><mailto:Concurrency-interest@cs.oswego.edu></a>
          <br>
              <a class="moz-txt-link-freetext" href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a>
          <br>
          <br>
          <br>
          <br>
          <br>
          _______________________________________________
          <br>
          Concurrency-interest mailing list
          <br>
          <a class="moz-txt-link-abbreviated" href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a>
          <br>
          <a class="moz-txt-link-freetext" href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a>
          <br>
        </blockquote>
        <br>
        <br>
        <br>
        _______________________________________________
        <br>
        Concurrency-interest mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a>
        <br>
        <a class="moz-txt-link-freetext" href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a>
        <br>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>