<head><!-- BaNnErBlUrFlE-HeAdEr-start -->
<style>
  #pfptBannerkopksd3 { all: revert !important; display: block !important;
    visibility: visible !important; opacity: 1 !important;
    background-color: #60beeb !important;
    max-width: none !important; max-height: none !important }
  .pfptPrimaryButtonkopksd3:hover, .pfptPrimaryButtonkopksd3:focus {
    background-color: #77a8c4 !important; }
  .pfptPrimaryButtonkopksd3:active {
    background-color: #8193a0 !important; }
  html:root, html:root>body { all: revert !important; display: block !important;
    visibility: visible !important; opacity: 1 !important; }
</style>

<!-- BaNnErBlUrFlE-HeAdEr-end -->
</head><!-- BaNnErBlUrFlE-BoDy-start -->
<!-- Preheader Text : BEGIN -->
<div style="display:none !important;display:none;visibility:hidden;mso-hide:all;font-size:1px;color:#ffffff;line-height:1px;max-height:0px;opacity:0;overflow:hidden;">
Dear HotSpot GC and Updates Team, I am writing to request a review of a potential root cause we have identified for intermittent data corruption issues in our JDK 17 production environments. The Symptom We run Apache Spark workloads on JDK 17</div>
<!-- Preheader Text : END -->

<!-- Email Banner : BEGIN -->
<div style="display:none !important;display:none;visibility:hidden;mso-hide:all;font-size:1px;color:#ffffff;line-height:1px;max-height:0px;opacity:0;overflow:hidden;">ZjQcmQRYFpfptBannerStart</div>

<!--[if ((ie)|(mso))]>
  <table border="0" cellspacing="0" cellpadding="0" width="100%" style="padding: 0px 0px 10px 0px; direction: ltr" lang="en"><tr><td>
    <table border="0" cellspacing="0" cellpadding="0" style="padding: 0px 8px 6px 8px; width: 100%; border-radius:4px; border-top:4px solid #8193a0;background-color:#60beeb;"><tr><td valign="top">
      <table align="left" border="0" cellspacing="0" cellpadding="0" style="padding: 0px 8px 4px 8px; font-size: 12px; line-height: 16px">
        <tr><td style="color:#000000; font-family: 'Arial', sans-serif; font-weight:bold; font-size:14px; line-height: 20px; direction: ltr">
          This Message Is From an External Sender
        </td></tr>
        <tr><td style="color:#000000; font-weight:normal; font-family: 'Arial', sans-serif; font-size:12px; direction: ltr">
          This message came from outside your organization.
        </td></tr>

      </table>
      <![if ie]><br clear="all"><![endif]>
      <table align="right" border="0" cellspacing="0" cellpadding="0" style="padding: 0px 0px 4px 0px; font-size: 14px; line-height: 36px"><tr>
        <td style="direction: ltr">  <a target="_blank" href="https://us-phishalarm-ewt.proofpoint.com/EWT/v1/ACWV5N9M2RV99hQ!Op20OCdhWoYGdX6sOjK4cPbOYPOFX0UuKymSG85Txjk_I0OqTgBTOz_xllxC69X3QJGbshEiZk3rOJZwqjktTBqhDEtXaCaJhB5uudNFpJVrouAqJYvmNPaD9LUANxO5ga3i$" style="mso-padding-alt: 7px; padding: 7px; border-radius: 2px; border: 1px solid #666666; "><strong style="font-weight: normal; color: #000000; text-decoration: none; font-family: 'Arial', sans-serif; font-size: 14px;">  Report Suspicious  </strong></a>  ‌ </td>
      </tr></table>
    </td></tr></table>
  </td></tr></table>
<![endif]-->

<![if !((ie)|(mso))]>
  <div dir="ltr" lang="en" id="pfptBannerkopksd3" style="all: revert !important; display:block !important; text-align: left !important; margin: 0 0 10px 0 !important; padding:7px 16px 8px 16px !important; border-radius: 4px !important; min-width: 200px !important; background-color: #60beeb !important; background-color: #60beeb; border-top: 4px solid #8193a0 !important; border-top: 4px solid #8193a0;">
    <div id="pfptBannerkopksd3" style="all: unset !important; float:left !important; display:block !important; margin: 1px 0 1px 0 !important; max-width: 600px !important;">
      <div id="pfptBannerkopksd3" style="all: unset !important; display:block !important; visibility: visible !important; background-color: #60beeb !important; color:#000000 !important; color:#000000; font-family: 'Arial', sans-serif !important; font-family: 'Arial', sans-serif; font-weight:bold !important; font-weight:bold; font-size:14px !important; line-height:1.29 !important; line-height:1.29">
        This Message Is From an External Sender
      </div>
      <div id="pfptBannerkopksd3" style="all: unset !important; display:block !important; visibility: visible !important; background-color: #60beeb !important; color:#000000 !important; color:#000000; font-weight:normal; font-family: 'Arial', sans-serif !important; font-family: 'Arial', sans-serif; font-size:12px !important; line-height:1.5 !important; line-height:1.5; margin-top:2px !important;">
This message came from outside your organization.
      </div>

    </div>
    <div id="pfptBannerkopksd3" style="all: unset !important; float: right !important; display: block !important; display: block; margin-left: 16px !important; margin-top: 1px !important; text-align: right !important; width: fit-content !important; font-size: 12px !important">
<a id="pfptBannerkopksd3" href="https://us-phishalarm-ewt.proofpoint.com/EWT/v1/ACWV5N9M2RV99hQ!Op20OCdhWoYGdX6sOjK4cPbOYPOFX0UuKymSG85Txjk_I0OqTgBTOz_xllxC69X3QJGbshEiZk3rOJZwqjktTBqhDEtXaCaJhB5uudNFpJVrouAqJYvmNPaD9LUANxO5ga3i$"
    style="all: unset !important; display: inline-block !important; text-decoration: none">
    <div class="pfptPrimaryButtonkopksd3" style="display: inline-block !important; display: inline-block; visibility: visible !important; opacity: 1 !important; color: #000000 !important; color: #000000; font-family: 'Arial', sans-serif !important; font-family: 'Arial', sans-serif; font-size: 14px !important;  font-weight: normal !important; text-decoration: none !important; border-radius: 2px !important; margin-top: 3px !important; margin-bottom: 3px !important; margin-left: 16px !important; padding: 7.5px 16px !important; white-space: nowrap !important; width: fit-content !important;
        border: 1px solid #666666">
        Report Suspicious
    </div>
</a>
    </div>
    <div style="clear: both !important; display: block !important; visibility: hidden !important; line-height: 0 !important; font-size: 0.01px !important; height: 0px"> </div>
  </div>
<![endif]>

<div style="display:none !important;display:none;visibility:hidden;mso-hide:all;font-size:1px;color:#ffffff;line-height:1px;max-height:0px;opacity:0;overflow:hidden;">ZjQcmQRYFpfptBannerEnd</div>
<!-- Email Banner : END -->

<!-- BaNnErBlUrFlE-BoDy-end -->
<div dir="ltr">Dear HotSpot GC and Updates Team,<div><br>I am writing to request a review of a potential root cause we have identified for intermittent data corruption issues in our JDK 17 production environments.</div><div><br><b>The Symptom</b><br>We run Apache Spark workloads on JDK 17 using <b>ParallelGC</b>. We observe intermittent java.io.IOException: FAILED_TO_UNCOMPRESS(5) errors coming from the Snappy native library. The stack traces indicate the failure occurs during VectorizedColumnReader operations, where GetPrimitiveArrayCritical is used to access on-heap byte arrays.</div><div><br><b>Hypothesis & Analysis</b><br>We suspect a race condition in jni_GetPrimitiveArrayCritical (specifically in jni.cpp / lock_gc_or_pin_object).</div><div><br>In the non-pinning path (used by G1 and ParallelGC), the code currently does:<br><br></div><div>// Current implementation<br>GCLocker::lock_critical(thread);<br>return JNIHandles::resolve_non_null(obj);</div><div><br>Our analysis suggests that because lock_critical does not strictly block an ongoing GC (it only prevents a new one from starting), it is possible for a GC cycle (specifically the compaction phase of ParallelGC) to move the object after it has been resolved by JNIHandles but before the critical section is effectively established for the native consumer. This would result in the native code receiving a pointer to the object's old memory address (stale pointer).<br><b><br></b></div><div><b>Proposed Fix</b><br>We have tested a patch that aligns the object locking mechanism with jni_GetStringCritical by using a Handle to protect the object pointer:<br>// Proposed fix<br>Handle h(thread, JNIHandles::resolve_non_null(obj));<br>GCLocker::lock_critical(thread);<br>return h();<br><br></div><div><b>Implementation & Verification</b><br>We have implemented this fix and added a comprehensive test suite that reproduces the issue. The commit can be reviewed here:<br><br></div><div><a href="https://github.com/wangyum/jdk17u-dev/commit/bf7f679587683d6035e26af31a61b6b789e5a9bd">https://github.com/wangyum/jdk17u-dev/commit/bf7f679587683d6035e26af31a61b6b789e5a9bd</a><br>The test suite includes a native stress test that specifically triggers GC within this critical window.<br>1.  Without the fix: We can reproduce data corruption and detect object address changes during the critical section using ParallelGC.<br>2.  With the fix: The corruption disappears, and the native code consistently accesses valid data.<br><br></div><div><b>Request</b><br>Could a VM expert please review this analysis and the proposed fix? We would like to confirm:<br>1.  Is our understanding of the lock_critical vs. object movement race correct for ParallelGC?<br>2.  Is the proposed Handle-based fix safe and appropriate for inclusion in JDK 17u?<br>Thank you for your time and guidance.</div></div>