<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Am 18.10.2017 um 10:18 schrieb Erik
      Österlund:<br>
    </div>
    <blockquote type="cite" cite="mid:59E70E49.4040207@oracle.com">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      Hi Roman,<br>
      <br>
      <div class="moz-cite-prefix">On 2017-10-17 23:34, Roman Kennke
        wrote:<br>
      </div>
      <blockquote
        cite="mid:3a72da30-b74f-a65e-1f06-adefb0e610c8@redhat.com"
        type="cite">
        <meta http-equiv="Content-Type" content="text/html;
          charset=utf-8">
        <div class="moz-cite-prefix">Am 17.10.2017 um 23:10 schrieb
          Roman Kennke:<br>
        </div>
        <blockquote type="cite"
          cite="mid:2dbc333b-d020-ca62-e5ed-7d3396728e7e@redhat.com">
          <meta http-equiv="Content-Type" content="text/html;
            charset=utf-8">
          <div class="moz-cite-prefix"><br>
          </div>
          <blockquote type="cite"
            cite="mid:0b96508f-2522-5b93-a271-9fd18aaeda28@redhat.com">
            <meta http-equiv="content-type" content="text/html;
              charset=utf-8">
            <p>The SuspendibleThreadSet API for synchronizing any
              non-Java thread with safepoints currently resides under
              gc/g1. It is very useful for other GCs too (in particular,
              Shenandoah does use it too), so I wanted to move it to a
              common location like gc/common. Then Kim Barrett commented
              that it might actually be useful for other threads outside
              GC land and to put it under runtime/. So I did:</p>
            <p><a moz-do-not-send="true"
                href="http://cr.openjdk.java.net/%7Erkennke/8189276/webrev.00/">http://cr.openjdk.java.net/~rkennke/8189276/webrev.00/</a></p>
            <p>I also added a generic hook to call the STS from
              safepoint sync/desync, which is consequently used by G1
              now. In other words, the CollectedHeap API that Erik Ö
              introduced is no longer used by G1. Only CMS still uses
              that API because it has its own way to sync with
              safepoints. I filed <a moz-do-not-send="true"
                href="https://bugs.openjdk.java.net/browse/JDK-8189364">another
                bug</a> for this. Although I have my doubt it will ever
              be fixed. This seems to have been very carefully evolved
              (to put it positive), and the risk of breaking it is
              relatively high, and thus doesn't seem worth the struggle
              to make it fit the STS.<br>
            </p>
            <p>Issue:<br>
              <a moz-do-not-send="true"
                href="https://bugs.openjdk.java.net/browse/JDK-8189276">https://bugs.openjdk.java.net/browse/JDK-8189276</a></p>
            <p>What do you think? Ok to go in?</p>
          </blockquote>
          Replying to myself here.<br>
          I must admit that I am a bit reluctant to expose it to
          runtime/ unless there's a specific need for it. So maybe go
          back to the original plan to move it into gc/common and leave
          all the rest alone for now? What do others think?<br>
        </blockquote>
        <br>
        Sorry, forgot to add something. One reason why we originally
        wanted to move it to gc/common (a new directory) instead of the
        existing gc/shared was that Erik H objected that gc/shared would
        be built into the minimal VM, and we probably wouldn't want that
        unless needed. However, moving it to runtime/ (without actual
        need), would achieve just that. So unless we can name an actual
        thread that would benefit from synchronizing using the STS, I
        suggest to leave the STS code in gc/common for now?<br>
        <br>
        That would be:<br>
        <a moz-do-not-send="true"
          href="http://cr.openjdk.java.net/%7Erkennke/8189276/webrev.01/">http://cr.openjdk.java.net/~rkennke/8189276/webrev.01/</a><br>
      </blockquote>
      <br>
      We had some internal discussions, and the conclusion seems to be
      that we would like to not have a new gc/common directory for
      build-only purposes, but rather put it in gc/shared and explicitly
      mark files we do not want to have compiled in minimal VM in the
      make/hotspot/lib/JvmFeatures.gmk build file. You can remove files
      from the minimal VM build by explicitly adding files to an exclude
      list in that file.<br>
      <br>
      133:  JVM_EXCLUDE_FILES += \<br>
      134:      concurrentGCThread.cpp \<br>
      +++ add your files here<br>
      135:      plab.cpp<br>
      <br>
      I tend to agree that avoiding the new gc/common directory is
      probably a win right now. Hope you agree with this.<br>
    </blockquote>
    Sure. This sounds like the best solution so far. Basically back to
    my original plan :-)<br>
    <br>
    <a moz-do-not-send="true"
      href="http://cr.openjdk.java.net/%7Erkennke/8189276/webrev.02/">http://cr.openjdk.java.net/~rkennke/8189276/webrev.02/</a><br>
    <br>
    Haven't tested minimal build though.<br>
    <br>
    Roman<br>
    <br>
  </body>
</html>