<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 21, 2013, at 7:41 AM, Albert Noll &lt;<a href="mailto:albert.noll@oracle.com">albert.noll@oracle.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi,<br>
      <br>
      vladimir, Christian, thanks for looking at the code. I fixed the
      type error as<br>
      well as another bug that was in the previous version<i><br>
        <br>
        <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~anoll/8014430/webrev.01/">http://cr.openjdk.java.net/~anoll/8014430/webrev.01/</a></i><i><br>
      </i><br>
      In the previous version:<br>
      <br>
      <pre><span class="new"> CompilerThread::current()-&gt;set_buffer_blob(buffer_blob);</span></pre>
      used "buffer_blob" instead of "blob".<br>
      <br>
      Please see the new version at:<br>
      <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~anoll/8014430/webrev.02/">http://cr.openjdk.java.net/~anoll/8014430/webrev.02/</a><br></div></div></blockquote><div><br></div>That looks good. &nbsp;-- Chris</div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#FFFFFF"><div class="moz-cite-prefix">
      <br>
      <br>
      I also looked at other places where C1 allocates memory from the
      code buffer. I found<br>
      a place in void Runtime1::generate_blob_for(). The current code
      uses asserts to check <br>
      the the allocation works.<br>
      <br>
      Do you think we should change anything about that?<br>
      <br>
      Best,<br>
      Albert<br>
      <br>
      <br>
      On 17.05.2013 19:24, Vladimir Kozlov wrote:<br>
    </div>
    <blockquote cite="mid:519667B3.5050804@oracle.com" type="cite">Albert,
      <br>
      <br>
      I assigned 7170965 to you. Close it if it is duplicate (which is,
      I think). But there is no mach info there (no call stack).
      <br>
      <br>
      Could you check all places in C1 which may ask for allocation in
      codecache?
      <br>
      <br>
      Thanks,
      <br>
      Vladimir
      <br>
      <br>
      On 5/17/13 10:05 AM, Christian Thalinger wrote:
      <br>
      <blockquote type="cite">
        <br>
        On May 17, 2013, at 6:21 AM, Albert Noll
        <a class="moz-txt-link-rfc2396E" href="mailto:albert.noll@oracle.com">&lt;albert.noll@oracle.com&gt;</a> wrote:
        <br>
        <br>
        <blockquote type="cite">Hi,
          <br>
          <br>
          I implemented the same behavior for C1 as there is in C2, if
          there is insufficient memory in the code cache to instantiate
          the compiler. I.e., only the interpreter is used.
          <br>
          <br>
          However, I am not quite sure if the current patch considers
          all variables that must be set (if there are any?) when
          compilation is aborted due to insufficient memory. So please
          take a close look!
          <br>
          <br>
          Many thanks,
          <br>
          Albert
          <br>
          <br>
          webrev: <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~anoll/8014430/webrev.01/">http://cr.openjdk.java.net/~anoll/8014430/webrev.01/</a>
          <br>
        </blockquote>
        <br>
        src/share/vm/c1/c1_Compiler.cpp:
        <br>
        <br>
        &nbsp;&nbsp; 97&nbsp;&nbsp;&nbsp;&nbsp; env-&gt;record_failure("Full CacheCache\n");
        <br>
        <br>
        Typo.&nbsp; In fact, can we use the same failure message as C2?
        <br>
        <br>
        &nbsp;&nbsp;&nbsp;&nbsp; C-&gt;record_failure("CodeCache is full");
        <br>
        <br>
        Otherwise this looks good to me.
        <br>
        <br>
        -- Chris
        <br>
        <br>
        <blockquote type="cite">
          <br>
          On 16.05.2013 17:57, Vladimir Kozlov wrote:
          <br>
          <blockquote type="cite">Thank you, Albert
            <br>
            <br>
            Yes, the behavior should be the same.
            <br>
            <br>
            Vladimir
            <br>
            <br>
            On 5/16/13 7:09 AM, Albert Noll wrote:
            <br>
            <blockquote type="cite">Hi,
              <br>
              <br>
              Vladimir, Christian, thanks for your feedback.
              <br>
              When -Xcomp or -server is used, hotspot starts up
              <br>
              and prints the following warning:
              <br>
              <br>
              Java HotSpot(TM) Server VM warning: CodeCache is full.
              Compiler has been disabled.
              <br>
              Java HotSpot(TM) Server VM warning: Try increasing the
              code cache size using -XX:ReservedCodeCacheSize=
              <br>
              CodeCache: size=1024Kb used=488Kb max_used=504Kb
              free=535Kb
              <br>
              &nbsp; bounds [0xf5fb4000, 0xf60b1000, 0xf60b4000]
              <br>
              &nbsp; total_blobs=271 nmethods=154 adapters=64
              <br>
              &nbsp; compilation: disabled (not enough contiguous free space
              left)
              <br>
              <br>
              <br>
              I suppose that is the behavior that we should also get
              when starting Hotspot
              <br>
              with -client. Sorry, I did not consider that.
              <br>
              <br>
              Best,
              <br>
              Albert
              <br>
              <br>
              <br>
              <br>
              <br>
              <br>
              On 15.05.2013 18:10, Vladimir Kozlov wrote:
              <br>
              <blockquote type="cite">There is an other duplicated bug
                assigned to Roland (serach jbs). We should wait for him
                to comment on this.
                <br>
                I think, we should not exit VM but only disable C1
                compilation as we do with C2.
                <br>
                Albert, could you verify C2 (sever vm) behavior in such
                situation?
                <br>
                Also what happens when -Xcomp is used?
                <br>
                <br>
                Thanks,
                <br>
                Vladimir
                <br>
                <br>
                On 5/15/13 2:49 AM, Albert Noll wrote:
                <br>
                <blockquote type="cite">Hi,
                  <br>
                  <br>
                  thank you for reviewing!
                  <br>
                  <br>
                  Best,
                  <br>
                  Albert
                  <br>
                  <br>
                  jbs: <a class="moz-txt-link-freetext" href="https://jbs.oracle.com/bugs/browse/JDK-8014430">https://jbs.oracle.com/bugs/browse/JDK-8014430</a>
                  <br>
                  webrev:
                  <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~anoll/8014430/webrev.00/">http://cr.openjdk.java.net/~anoll/8014430/webrev.00/</a>
                  <a class="moz-txt-link-rfc2396E" href="http://cr.openjdk.java.net/%7Eanoll/8014430/webrev.00/">&lt;http://cr.openjdk.java.net/%7Eanoll/8014430/webrev.00/&gt;</a>
                  <br>
                  <br>
                  Problem: VM failed with the following error message
                  when the specified code cache
                  <br>
                  specified by -XX:ReservedCodeCacheSize=... is too
                  small to startup the VM.
                  <br>
                  <br>
                  #
                  <br>
                  # A fatal error has been detected by the Java Runtime
                  Environment:
                  <br>
                  #
                  <br>
                  #&nbsp; Internal Error (c1_Compiler.cpp:87), pid=25077,
                  tid=3856251760
                  <br>
                  #&nbsp; guarantee(blob != NULL) failed: must create initial
                  code buffer
                  <br>
                  #
                  <br>
                  # JRE version: Java(TM) SE Runtime Environment
                  (8.0-b89) (build 1.8.0-ea-b89)
                  <br>
                  # Java VM: Java HotSpot(TM) Client VM (25.0-b31 mixed
                  mode linux-x86 )
                  <br>
                  # Failed to write core dump. Core dumps have been
                  disabled. To enable core dumping, try "ulimit -c
                  unlimited" before
                  <br>
                  starting Java again
                  <br>
                  #
                  <br>
                  # If you would like to submit a bug report, please
                  visit:
                  <br>
                  #<a class="moz-txt-link-freetext" href="http://bugreport.sun.com/bugreport/crash.jsp">http://bugreport.sun.com/bugreport/crash.jsp</a>
                  <br>
                  #
                  <br>
                  <br>
                  <br>
                  Solution: replace guarantee() with&nbsp;
                  vm_exit_out_of_memory() to provide a
                  <br>
                  graceful shutdown of the VM if the specified size for
                  the code cache is too small
                  <br>
                  to startup the VM. The error message is now as
                  follows:
                  <br>
                  <br>
                  anoll@anoll-ThinkPad-T430:/export/anoll/test$
                  /export/anoll/jdk_export-32bit/jdk1.8.0/bin/java
                  -client
                  <br>
                  -XX:InitialCodeCacheSize=500k
                  -XX:ReservedCodeCacheSize=1m
                  MultipleClassLoaderCCFiller
                  <br>
                  #
                  <br>
                  # There is insufficient memory for the Java Runtime
                  Environment to continue.
                  <br>
                  # Native memory allocation (malloc) failed to allocate
                  288358 bytes for Compiler1 temporary CodeBuffer.
                  <br>
                  # Try to increase -XX:ReservedCodeCacheSize=.
                  <br>
                  <br>
                  # An error report file with more information is saved
                  as:
                  <br>
                  # /export/anoll/test/hs_err_pid22080.log
                  <br>
                  #
                  <br>
                  # Compiler replay data is saved as:
                  <br>
                  # /export/anoll/test/replay_pid22080.log
                  <br>
                  <br>
                </blockquote>
              </blockquote>
              <br>
            </blockquote>
          </blockquote>
          <br>
        </blockquote>
        <br>
      </blockquote>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></body></html>