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.06.08.47.16;	author pho;	state Exp;
branches;
next	;
commitid	crtwqAUAj7v3dE5G;


desc
@@


1.1
log
@lang/openjdk17: 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 implementation details of a particular chip is
fundamentally unsound, and that's why it didn't work on Apple Silicon in
the first place.

But since the upstream has stated they are knowingly doing this, the chance
of these patches getting accepted is slim, if not zero.

Also backported fixes regarding floating point arithmetics that appeared in
OpenJDK 22.
@
text
@$NetBSD: patch-src_hotspot_cpu_aarch64_templateInterpreterGenerator__aarch64.cpp,v 1.1 2025/08/04 13:22:06 pho Exp $

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

--- src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp.orig	2025-08-01 18:02:38.517120527 +0000
+++ src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
@@@@ -1365,6 +1365,9 @@@@ address TemplateInterpreterGenerator::ge
   __ get_method(rmethod);
   // result potentially in r0 or v0
 
+  // Restore cpu control state after JNI call
+  __ restore_cpu_control_state_after_jni(rscratch1, rscratch2);
+
   // make room for the pushes we're about to do
   __ sub(rscratch1, esp, 4 * wordSize);
   __ andr(sp, rscratch1, -16);
@