<p dir="ltr">There are also VM args to override the compilation thresholds; if extra trips through the methods don't yield better profile for a given app, they can be reduced.</p>
<p dir="ltr">Sent from my phone</p>
<div class="gmail_quote">On Feb 7, 2013 12:38 PM, "Nathan Reynolds" <<a href="mailto:nathan.reynolds@oracle.com">nathan.reynolds@oracle.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>> Why is there no way to serialize
      the performance statistics collected, or even the JIT compiled
      code and reload those on startup?<br>
      <br>
      I've wondered the same thing.  Before I brought it up a couple of
      years ago, it had already been considered.  The problem is that it
      takes more time to verify that the classes are the same than it
      does to just compile it anew.  Because of inlining, the number of
      classes that have to be considered is very large for just one
      optimized method.<br>
      <br>
      There are Ahead of Time compilers out there.  (See
      <a href="http://en.wikipedia.org/wiki/AOT_compiler" target="_blank">http://en.wikipedia.org/wiki/AOT_compiler</a>)  AOT has its
      drawbacks... "AOT can't usually perform some optimizations
      possible in JIT, like runtime profile-guided optimizations,
      pseudo-constant propagation or indirect/virtual function
      inlining."  HotSpot depends upon these optimizations heavily to
      improve performance.<br>
      <br>
      On the bright side, Class Data Sharing
      (<a href="http://en.wikipedia.org/wiki/Java_performance#Class_data_sharing" target="_blank">http://en.wikipedia.org/wiki/Java_performance#Class_data_sharing</a>)
      does help reduce start up time.  I think this feature is being
      enhanced, but I am not sure.<br>
      <br>
      <div><a href="http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds" target="_blank">Nathan
          Reynolds</a> | Architect | <a href="tel:602.333.9091" value="+16023339091" target="_blank">602.333.9091</a><br>
        <font color="red">Oracle</font> <a href="http://psr.us.oracle.com/" target="_blank">PSR Engineering</a> | Server
        Technology<br>
      </div>
      On 2/7/2013 10:17 AM, Nitsan Wakart wrote:<br>
    </div>
    <blockquote type="cite">
      <div style="font-size:10pt;font-family:arial,helvetica,sans-serif">This is probably mostly
        relevant for server applications, where the usage and hardware
        are static and the same software is run for months on end. Why
        is there no way to serialize the performance statistics
        collected, or even the JIT compiled code and reload those on
        startup?<br>
        <div><span><br>
          </span></div>
        <div><br>
        </div>
        <div style="font-family:arial,helvetica,sans-serif;font-size:10pt">
          <div style="font-family:times new roman,new york,times,serif;font-size:12pt">
            <div dir="ltr"> <font face="Arial">
                <hr size="1"> <b><span style="font-weight:bold">From:</span></b>
                Stanimir Simeonoff <a href="mailto:stanimir@riflexo.com" target="_blank"><stanimir@riflexo.com></a><br>
                <b><span style="font-weight:bold">To:</span></b>
                <a href="mailto:gregg.wonderly@pobox.com" target="_blank">gregg.wonderly@pobox.com</a> <br>
                <b><span style="font-weight:bold">Cc:</span></b>
                <a href="mailto:concurrency-interest@cs.oswego.edu" target="_blank">concurrency-interest@cs.oswego.edu</a> <br>
                <b><span style="font-weight:bold">Sent:</span></b>
                Thursday, February 7, 2013 4:56 PM<br>
                <b><span style="font-weight:bold">Subject:</span></b>
                Re: [concurrency-interest] Thread priority<br>
              </font> </div>
            <br>
            <div>Besides the iteration counts the JVM
              (may) add profiling data. For instance: call sites. If the
              method is compiled w/ a single class only and then another
              is loaded the method has to be deoptimized and optimized
              again - obviously unwanted behavior. The same holds true
              for inline caches.<br>
              <br>
              To put it simply: w/o the profiling data the resulting
              machine code may not be of high quality. More also if the
              compiling threshold is too low - that would result in a
              lot of "code cache" used and it increases memory footprint
              + it may reach the memory limit for the code cache as many
              invocations do not reach c2 (10k). There was such a bug
              introduced w/ the tiered compilation in 6.0.25 - basically
              it reached the 32mb of code cache super fast - and a lot
              of code didn't reach C2 at all (or even c1 and remained
              interpreted). I had to increase the code cache limits to
              ~256mb (staring off 32mb) to reach to quota and decided to
              turn off tiered compilation altogether. There was a rare
              bug as well, replacing c1 w/ c2 code resulted in crashing
              the process.<br>
              So, having low threshold is probably good for some
              microbenchmarks but not so much for real applications.<br>
              <br>
              Stanimir<br>
              <br>
              <div>On Thu, Feb 7, 2013
                at 6:08 PM, Gregg Wonderly <span dir="ltr"><<a rel="nofollow" href="mailto:gregg@cytetech.com" target="_blank">gregg@cytetech.com</a>></span>
                wrote:<br>
                <blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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
                  <div><br>
                    <br>
                    On 2/7/2013 9:49 AM, Nathan Reynolds wrote:<br>
                  </div>
                  <blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
                    <div>
                      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>
                    </div>
                    Nathan Reynolds
                    <a href="http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds" target="_blank"><http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds></a>
                    |<br>
                    Architect | <a rel="nofollow">602.333.9091</a><br>
                    Oracle PSR Engineering
                    <a href="http://psr.us.oracle.com/" target="_blank"><http://psr.us.oracle.com/></a> | Server
                    Technology
                    <div><br>
                      On 2/7/2013 12:21 AM, Stanimir Simeonoff wrote:<br>
                    </div>
                    <blockquote style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
                      <div>
                        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>
                      </div>
                      <div>
                        <<a rel="nofollow" href="mailto:radhakrishnan.mohan@gmail.com" target="_blank">radhakrishnan.mohan@gmail.com</a>
                        <mailto:<a rel="nofollow" href="mailto:radhakrishnan.mohan@gmail.com" target="_blank">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>
                      </div>
                          <a rel="nofollow" href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a>
                      <mailto:<a rel="nofollow" href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a>>
                      <div>
                        <br>
                            <a rel="nofollow" href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
                        <br>
                        <br>
                        <br>
                        <br>
                        _______________________________________________<br>
                        Concurrency-interest mailing list<br>
                        <a rel="nofollow" href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
                        <a rel="nofollow" href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
                      </div>
                    </blockquote>
                    <div>
                      <br>
                      <br>
                      <br>
                      _______________________________________________<br>
                      Concurrency-interest mailing list<br>
                      <a rel="nofollow" href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
                      <a rel="nofollow" href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
                      <br>
                    </div>
                  </blockquote>
                  <div>
                    <div>
                      <br>
                      _______________________________________________<br>
                      Concurrency-interest mailing list<br>
                      <a rel="nofollow" href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
                      <a rel="nofollow" href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
                    </div>
                  </div>
                </blockquote>
              </div>
              <br>
            </div>
            <br>
            _______________________________________________<br>
            Concurrency-interest mailing list<br>
            <a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
            <a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
            <br>
            <br>
          </div>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Concurrency-interest mailing list
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a>
</pre>
    </blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
<br></blockquote></div>