<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 16:48 schrieb Roman
      Kennke:<br>
    </div>
    <blockquote type="cite"
      cite="mid:e6d4b36b-5020-8a2c-8aab-016bdac87abd@redhat.com">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <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>
    </blockquote>
    Sorry, forget that patch. I uploaded the wrong webrev. Here's the
    correct one:<br>
    <br>
    <a moz-do-not-send="true"
      href="http://cr.openjdk.java.net/%7Erkennke/8189276/webrev.03/">http://cr.openjdk.java.net/~rkennke/8189276/webrev.03/</a><br>
    <br>
    Roman<br>
  </body>
</html>