<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hello Chris,</p>
    <p>In the past the OCA verification has sometimes taken more than a
      week or two, so please wait a few more days for the verification
      to be completed. <br>
    </p>
    <p>-Jaikiran<br>
    </p>
    <div class="moz-cite-prefix">On 23/07/25 4:30 am, Chris Dennis
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAM1ck5guQ8MtK2UwKjLq0URyfFZNj2bUy+CrBdNxmda67951sQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>Is there a process I can (or should?) be following to get
          my PR for fixing this through OCA verification, or do I just
          need to be a little more patient?</div>
        <div><br>
        </div>
        <div>Thanks,</div>
        <div><br>
        </div>
        <div>Chris</div>
        <br>
        <div class="gmail_quote gmail_quote_container">
          <div dir="ltr" class="gmail_attr">On Tue, 15 Jul 2025 at
            07:59, Chris Dennis <<a
              href="mailto:chris.w.dennis@gmail.com"
              moz-do-not-send="true" class="moz-txt-link-freetext">chris.w.dennis@gmail.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
            <div dir="ltr">Apologies, that description is pretty lousy.
              A more explicit description of the leak (the one in my
              test in <a
                href="https://github.com/openjdk/jdk/pull/26296"
                target="_blank" moz-do-not-send="true"
                class="moz-txt-link-freetext">https://github.com/openjdk/jdk/pull/26296</a>)
              would be: A class loaded by classloader 'C' statically
              references an Executor created via
              newSingleThreadExecutor(threadFactory). The ThreadFactory
              is an instance of a class also loaded by 'C'. This
              executor is then shutdown via shutdownNow(). The resulting
              structure will pin the classloader 'C' in memory.
              <div><br>
              </div>
              <div>Chris</div>
            </div>
            <br>
            <div class="gmail_quote">
              <div dir="ltr" class="gmail_attr">On Tue, 15 Jul 2025 at
                06:50, Alan Bateman <<a
                  href="mailto:alan.bateman@oracle.com" target="_blank"
                  moz-do-not-send="true" class="moz-txt-link-freetext">alan.bateman@oracle.com</a>>
                wrote:<br>
              </div>
              <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On
                11/07/2025 15:42, Chris Dennis wrote:<br>
                > Hi All,<br>
                ><br>
                > I believe I've identified a bug in <br>
                > Executors.AutoShutdownDelegatedExecutorService that
                can trigger a <br>
                > classloader leak even in the presence of "correct"
                Executor <br>
                > lifecycling. AutoShutdownDelegatedExecutorService
                only unlinks the <br>
                > PhantomReference used for cleanup handling when it
                is shutdown via the <br>
                > shutdown() method. If an Executor wrapped in this
                way is instead <br>
                > shutdown using the shutdownNow() method and it
                references a <br>
                > classloader via an injected attribute:
                ThreadFactory, AbortPolicy, <br>
                > etc. then the cleanup action will reference the
                classloader, and the <br>
                > classloader will remain strongly referenced. Adding
                an additional <br>
                > override as shown in the attached patch is
                sufficient to fix the leak <br>
                > in my testing.<br>
                ><br>
                It would be useful if you could say more about the
                scenario. The cleaner <br>
                should execute once the executor service is eligible to
                be GC'ed and the <br>
                reference is queued. Invoking shutdown just means it is
                early <br>
                unregistered. So I'm wondering if your issue is more
                about timing in <br>
                that it's not being GC'ed in a timely manner.<br>
                <br>
                -Alan<br>
              </blockquote>
            </div>
          </blockquote>
        </div>
      </div>
    </blockquote>
  </body>
</html>