head	1.1;
access;
symbols
	pkgsrc-2026Q1:1.1.0.6
	pkgsrc-2026Q1-base:1.1
	pkgsrc-2025Q4:1.1.0.4
	pkgsrc-2025Q4-base:1.1
	pkgsrc-2025Q3:1.1.0.2
	pkgsrc-2025Q3-base:1.1;
locks; strict;
comment	@// @;


1.1
date	2025.08.04.13.22.06;	author pho;	state Exp;
branches;
next	;
commitid	hLvjvkVJi5XjNp5G;


desc
@@


1.1
log
@lang/openjdk11: Workaround for the VM dying on Apple Silicon chips

See the patch for threadWXSetters.inline.hpp for details. I rebuilt the
bootkit for aarch64 with new patches applied. This may cause some
performance regression on Cortex series, but as I stated in the patch
comment, relying on assumptions made on implementation details of chips is
fundamentally unsound, and that's why it didn't work on Apple Silicon in
the first place.

Also backported fixes regarding floating point arithmetics that appeared in
OpenJDK 22.
@
text
@$NetBSD$

Backport a bugfix appeared in Java 22:
https://github.com/openjdk/jdk/commit/50f31240555888018f0f496ab29c8a5932dce459

--- src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp.orig	2025-08-01 18:07:27.105868141 +0000
+++ src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
@@@@ -3670,6 +3670,23 @@@@ void MacroAssembler::load_klass(Register
   }
 }
 
+void MacroAssembler::restore_cpu_control_state_after_jni(Register tmp1, Register tmp2) {
+  if (RestoreMXCSROnJNICalls) {
+    Label OK;
+    get_fpcr(tmp1);
+    mov(tmp2, tmp1);
+    // Set FPCR to the state we need. We do want Round to Nearest. We
+    // don't want non-IEEE rounding modes or floating-point traps.
+    bfi(tmp1, zr, 22, 4); // Clear DN, FZ, and Rmode
+    bfi(tmp1, zr, 8, 5);  // Clear exception-control bits (8-12)
+    bfi(tmp1, zr, 0, 2);  // Clear AH:FIZ
+    eor(tmp2, tmp1, tmp2);
+    cbz(tmp2, OK);        // Only reset FPCR if it's wrong
+    set_fpcr(tmp1);
+    bind(OK);
+  }
+}
+
 // ((OopHandle)result).resolve();
 void MacroAssembler::resolve_oop_handle(Register result, Register tmp) {
   // OopHandle::resolve is an indirection.
@