On Thu, 15 Jan 2026 15:03:29 GMT, Frederic Parain <[email protected]> wrote:
>> Hello, >> >> Update: There is nothing wrong with the logic. I added a comment to clarify >> why the second null-marker check is needed. Thanks. >> >> ~~Right now we check the null-marker for the NULLABLE_ATOMIC_FLAT LayoutKind >> twice, both before and after allocating a heap instance. The first check >> returns nullptr early if the null-marker is set, as we don't have to >> allocate an object on the heap if we are going to return nullptr anyways. >> The other check is redundant, since if the null-marker is not set, the >> source object is non-null, which means the destination (res) object is >> non-null as well after copying, so the code inside it is unreachable.~~ >> >> Testing: >> * Oracle's tier1-4, hotspot_valhalla, jdk_valhalla >> * ~~I also added a `gurantee` for the removed code and ran through >> hotspot_valhalla and jdk_valhalla locally.~~ > > Adding a comment to explain the rational of the second null-marker check is a > good idea. Thank you for the reviews @fparain @Arraying! ------------- PR Comment: https://git.openjdk.org/valhalla/pull/1914#issuecomment-3767189673
