<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    There are many optimizations that are useful with profiling data. 
    For example, I was surprised the other day that a virtual method got
    inlined!  The profile showed that only 1 class of many was being
    called into.  So, the optimizer put an if statement to check the
    class (3 cycle penalty) and then inlined the virtual method.  The
    check branches out to slower code if a different class is
    encountered.  Without profiling data, the optimizer would have to
    assume that any class was equally likely and therefore leave it as a
    pure virtual call.  However, if I had switch to 100 invocations then
    optimize, the code would have been just as good in this case.  The
    profile samples would have said the same thing to the optimizer.<br>
    <br>
    <div class="moz-signature"><a
        href="http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds">Nathan
        Reynolds</a> | Consulting Member of Technical Staff |
      602.333.9091<br>
      <font color="red">Oracle</font> <a
        href="http://psr.us.oracle.com/">PSR Engineering</a> | Server
      Technology<br>
    </div>
    <br>
    On 11/22/2011 9:52 AM, Gregg Wonderly wrote:
    <blockquote cite="mid:4ECBD348.5090400@cytetech.com" type="cite">Nathan,
      thanks for your insight.  My experience is that most of my code
      does absolutely little which would be "tuned" for improved
      throughput by an optimizer.  Instead, my applications are largely
      client server and remote communications based, and the vast
      majority of wall clock time involves latency in communications
      between machines.
      <br>
      <br>
      The SecurityManager, Permission, PermissionCollection and other
      related classes are absolutely at odds with throughput because of
      course grained locking and other extremely poor design choices. 
      Use of a SecurityManager seems like it is a much overlooked part
      of the JVM performance.
      <br>
      <br>
      We have things like the use of reflection in subclasses of Thread
      and "locking" to single threaded construction (a static container
      of all things) which kills throughput, no matter when the Jit
      takes over because of
      <br>
      <br>
          private static boolean isCCLOverridden(Class cl);
      <br>
      <br>
      That mechanism should be using Future (inside CHM perhaps) and not
      synchronized().  This can, to some degree be worked around by
      using a Runnable, instead, but sometimes a Thread is what works
      better because of its accessibility through Thread.currentThread()
      and yes you could use ThreadLocal instead for many cases.  But,
      subclassing thread for a Thread factory can be a necessity, and
      that's where many server kinds of applications with a security
      manager active get into trouble.
      <br>
      <br>
      For me, anything with a security manager that is a client, starts
      much faster with 100 invocations.  If there is anything
      appreciable that I miss by compiling that soon, I've not noticed
      it.
      <br>
      <br>
      Your discussion on heuristics being used to make more intelligent
      decisions about what optimizations might be beneficial (branch
      optimizations I'm guessing) help me see that there might be some
      better reasons to delay for some heavily compute bound classes.
      <br>
      <br>
      Gregg
      <br>
      <br>
      On 11/21/2011 5:29 PM, Nathan Reynolds wrote:
      <br>
      <blockquote type="cite">The JVM does profile-guided optimization.
        If you reduce the warm up to only 100
        <br>
        invocations, then the JVM only looks at those 100 samples and
        determines how to
        <br>
        optimize the method. I would guess that for some methods 100, or
        1000 or 10000
        <br>
        invocations isn't going to make any difference on the optimized
        code. However,
        <br>
        other methods need the full 10,000 invocations in order to fully
        understand how
        <br>
        the method is used and the best way to optimize it.
        <br>
        <br>
        In production, you could start one JVM with 100 invocations and
        the other with
        <br>
        the default. If both JVMs have the same CPU usage, response
        times and throughput
        <br>
        after warmup and compilation, then 100 invocations is sufficient
        for your
        <br>
        workload. I would guess that the one with 100 invocations will
        suffer.
        <br>
        <br>
        I'm not sure, but I believe HotSpot 7 includes a tiered
        compilation. After 1,000
        <br>
        invocations, the method is deemed hot enough that the JVM
        optimizes it without
        <br>
        any profiling data to guide the optimizations. The JVM adds
        profiling code to
        <br>
        the method at this time. After 10,000 invocations, the JVM does
        the
        <br>
        profile-guided optimization of the method.
        <br>
        <br>
        On a heavily used server, 10,000 invocations should happen very
        quickly. For
        <br>
        some servers, they will process that many requests per second or
        even
        <br>
        sub-second. So, the question becomes does the first few minutes
        of execution
        <br>
        really matter considering the lifespan of the server? In the
        overall picture,
        <br>
        the start up time is much less than 1% of the total time the
        server is running.
        <br>
        <br>
        For client applications, this is a much different story. The
        10,000 invocation
        <br>
        won't be reached until the user presses a button 10,000 times.
        However, _some_
        <br>
        of the time the response time of the program isn't critical. The
        response time
        <br>
        for fully optimized code might be 1 ms. With unoptimized code it
        might be 10 ms.
        <br>
        The user may not be able to notice. For example, the older
        flat-panel monitors
        <br>
        refresh at 60 Hz (= 16.6 ms). So, if the program responds within
        16.6 ms, the
        <br>
        user may not even be able to see that it took a bit longer.
        <br>
        <br>
        However, I hear your pain. I wish there were a good way to have
        instant warm up.
        <br>
        I and several others have given this problem a lot of thought.
        All of the
        <br>
        schemes we have come up with have a lot of issues and were
        rejected flat-out or
        <br>
        were tried and then rejected due to performance issues.
        <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>
        Consulting Member of Technical Staff | 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>
        <br>
        On 11/21/2011 3:36 PM, Gregg Wonderly wrote:
        <br>
        <blockquote type="cite">So I have to ask, why don't you use the
          command line property to change this
          <br>
          to something like 100 for a faster warm up? For some of my
          applications, doing
          <br>
          this reduces startup time by orders of magnitude because of
          the number of
          <br>
          times some things are invoked. In particular, server
          applications using a
          <br>
          security manager seem to start much faster.
          <br>
          <br>
          Gregg Wonderly
          <br>
          <br>
          On 11/21/2011 3:40 PM, Nathan Reynolds wrote:
          <br>
          <blockquote type="cite">Microbenchmarks are incredibly hard to
            get right. For example, HotSpot 7 JVM
            <br>
            won't do a full optimization of a method until 10,000
            invocations. You need to
            <br>
            bump up the priority of the test thread so that other things
            on the system don't
            <br>
            add noise. These probably aren't applicable to your case,
            but you may to force a
            <br>
            full GC right before running the test.
            <br>
            <br>
            You probably want to use <a class="moz-txt-link-freetext" href="http://code.google.com/p/caliper/">http://code.google.com/p/caliper/</a>
            which deals with all
            <br>
            of these gotchas.
            <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>
            Consulting Member of Technical Staff | 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>
            <br>
            On 11/21/2011 2:15 PM, David Harrigan wrote:
            <br>
            <blockquote type="cite">Hi Everyone,
              <br>
              <br>
              I'm learning about the fork and join framework in JDK7 and
              to test it
              <br>
              out I wrote a little program that tries to find a number
              at the end of
              <br>
              a list with 50,000 elements.
              <br>
              What puzzles me is when I run the "find" in a sequential
              fashion, it
              <br>
              returns faster than if I use a fork-and-join
              implementation. I'm
              <br>
              running each "find" 5000 times
              <br>
              so as to "warm" up the JVM. I've got a timing listed
              below:
              <br>
              <br>
              Generating some data...done!
              <br>
              Sequential
              <br>
              Simon Stopwatch: total 1015 s, counter 5000, max 292 ms,
              min 195 ms,
              <br>
              mean 203 ms [sequential INHERIT]
              <br>
              Parallel
              <br>
              Simon Stopwatch: total 1352 s, counter 5000, max 4.70 s,
              min 243 ms,
              <br>
              mean 270 ms [parallel INHERIT]
              <br>
              <br>
              (some runtime information)
              <br>
              <br>
              openjdk version "1.7.0-ea"
              <br>
              OpenJDK Runtime Environment (build 1.7.0-ea-b215)
              <br>
              OpenJDK 64-Bit Server VM (build 21.0-b17, mixed mode)
              <br>
              <br>
              2.66Mhz Intel Core i7 with 8GB RAM (256KB L2 cache per
              core (4 cores)
              <br>
              and 4MB L3 cache) running on a MBP (Lion 10.7.2)
              <br>
              <br>
              Forgive my ignorance but this type of programming is still
              quite new
              <br>
              to me and I'm obviously doing something wrong, but I don't
              know what.
              <br>
              My suspicion is
              <br>
              something to do with spinning up and down threads and the
              overhead
              <br>
              that entails. I've posted the src
              herehttp://pastebin.com/p96R24R0.
              <br>
              <br>
              My sincere apologies if this list is not appropriate for
              this posting,
              <br>
              if so I would welcome a pointer on where I can find more
              information
              <br>
              to help me understand
              <br>
              better the behaviour of my program when using F&J.
              <br>
              <br>
              I thought that by using F&J I would be able to find
              the answer quicker
              <br>
              than doing the searching sequentially, perhaps I've
              choosen a wrong
              <br>
              initial problem to
              <br>
              test this out (something that is suited to a sequential
              search and not
              <br>
              a parallel search?)
              <br>
              <br>
              Thank you all in advance.
              <br>
              <br>
              -=david=-
              <br>
              <br>
            </blockquote>
            <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>
        </blockquote>
      </blockquote>
      <br>
    </blockquote>
  </body>
</html>