<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Hello Shaojin,</p>
    <p>Looking at the proposed change, the proposal here appears to be
      to replace an inline "new DateTimeException(...)" call with a call
      to a new private method which returns a "new
      DateTimeException(...)", to please the hotspot compiler's inlining
      decision.</p>
    <p>I think this isn't a useful change. Enabling the
      -XX:+PrintInlining will naturally print the runtime compiler's
      inlining decisions and there could be some/many logs which
      complain that the method couldn't be inlined. Changing the java
      code (like here) to closely handhold it to match the (unspecified)
      expectations of a particular (current) implementation of the
      runtime compiler shouldn't be the way to code in java language.
      Such changes, like the one here, won't help with the
      maintainability or the readability of the code.<br>
    </p>
    <p>-Jaikiran<br>
    </p>
    <div class="moz-cite-prefix">On 05/08/25 6:55 am, wenshao wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:62d992ec-5a3c-4436-be49-a692379402c4.shaojin.wensj@alibaba-inc.com">
      
      <div class="__aliyun_email_body_block">
        <div style="font-family: Tahoma, Arial, STHeitiSC-Light, SimSun">
          <div style="clear: both;"><span>By adding the JVM startup
              parameters `-XX:+UnlockDiagnosticVMOptions
              -XX:+PrintInlining` and analyzing the printed log
              information, and found that the code size of the
              j.t.f.DateTimePrintContext::adjust method is 382, which is
              greater than 325, causing inlining failure.</span>
            <div style="clear: both;"><br>
            </div>
            <div style="clear: both;">Below is the log message:</div>
            <div style="clear: both;">```</div>
            <div style="clear: both;">@ 7  
              java.time.format.DateTimePrintContext::adjust (382 bytes)
                failed to inline: hot method too big</div>
            <div style="clear: both;">```</div>
            <div style="clear: both;"><br>
            </div>
            <span>We can extract the exception-generating code into two
              smaller methods, reducing the code size from 382 to 322,
              allowing C2 to inline the DateTimePrintContext::adjust
              method.</span></div>
          <div style="clear: both;"><br>
          </div>
          <div style="clear: both;"><span>The refactored code looks like
              this:</span></div>
          <div style="clear: both;"><span>```java</span>
            <div style="clear: both;">    private static
              TemporalAccessor adjust(final TemporalAccessor temporal,
              DateTimeFormatter formatter) {</div>
            <div style="clear: both;">        // ...</div>
            <div style="clear: both;">        if
              (overrideZone.normalized() instanceof ZoneOffset
              && temporal.isSupported(OFFSET_SECONDS) &&</div>
            <div style="clear: both;">               
              temporal.get(OFFSET_SECONDS) !=
              overrideZone.getRules().getOffset(Instant.EPOCH).getTotalSeconds())
              {</div>
            <div style="clear: both;">            throw
              unableApplyOverrideZone(temporal, overrideZone);</div>
            <div style="clear: both;">        }</div>
            <div style="clear: both;">        // ....</div>
            <div style="clear: both;">        if (f.isDateBased()
              && temporal.isSupported(f)) {</div>
            <div style="clear: both;">            throw
              unableApplyOverrideChronology(temporal, overrideChrono);</div>
            <div style="clear: both;">        // ...</div>
            <div style="clear: both;">    }</div>
            <div style="clear: both;">    private static
              DateTimeException
              unableApplyOverrideChronology(TemporalAccessor temporal,
              Chronology overrideChrono) {</div>
            <div style="clear: both;">        return new
              DateTimeException("Unable to apply override chronology '"
              + overrideChrono +</div>
            <div style="clear: both;">                "' because the
              temporal object being formatted contains date fields but"
              +</div>
            <div style="clear: both;">                " does not
              represent a whole date: " + temporal);</div>
            <div style="clear: both;">    }</div>
            <div style="clear: both;">    private static
              DateTimeException unableApplyOverrideZone(TemporalAccessor
              temporal, ZoneId overrideZone) {</div>
            <div style="clear: both;">        return new
              DateTimeException("Unable to apply override zone '" +
              overrideZone +</div>
            <div style="clear: both;">                "' because the
              temporal object being formatted has a different offset
              but" +</div>
            <div style="clear: both;">                " does not
              represent an instant: " + temporal);</div>
            <div style="clear: both;">    }</div>
            <div><span>```</span></div>
            <div><span><br>
              </span></div>
            <div><span><span>I submitted a draft Pull Request <a href="https://github.com/openjdk/jdk/pull/26633" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jdk/pull/26633</a> , <span>Hope
                    to get your feedback.</span></span></span></div>
            <div><span><span><span><br>
                  </span></span></span></div>
            <div><span><span><span>-</span></span></span></div>
            <div><span><span><span>Shaojin Wen</span></span></span></div>
            <span></span></div>
        </div>
      </div>
    </blockquote>
  </body>
</html>