From debbugs-submit-bounces@debbugs.gnu.org Sun Jun 07 11:18:56 2020 Received: (at submit) by debbugs.gnu.org; 7 Jun 2020 15:18:57 +0000 Received: from localhost ([127.0.0.1]:54610 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhx4a-0006pS-KX for submit@debbugs.gnu.org; Sun, 07 Jun 2020 11:18:56 -0400 Received: from lists.gnu.org ([209.51.188.17]:51090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jhx4Z-0006pL-EA for submit@debbugs.gnu.org; Sun, 07 Jun 2020 11:18:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37308) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhx4Z-0000BF-9B for guix-patches@gnu.org; Sun, 07 Jun 2020 11:18:55 -0400 Received: from mailout.easymail.ca ([64.68.200.34]:54534) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jhx4Y-0005t9-0o for guix-patches@gnu.org; Sun, 07 Jun 2020 11:18:55 -0400 Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 2684D214A7; Sun, 7 Jun 2020 15:18:52 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at emo06-pco.easydns.vpn Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (emo06-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rU9Ad7KC1Jtt; Sun, 7 Jun 2020 15:18:51 +0000 (UTC) Received: from localhost.localdomain (unknown [108.162.141.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 55B3021403; Sun, 7 Jun 2020 15:18:49 +0000 (UTC) From: Simon South To: guix-patches@gnu.org Subject: [PATCH 0/1] Fix JamVM to work with current gcc and glibc Date: Sun, 7 Jun 2020 11:17:09 -0400 Message-Id: <20200607151709.21821-1-simon@simonsouth.net> X-Mailer: git-send-email 2.25.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=64.68.200.34; envelope-from=simon@simonsouth.net; helo=mailout.easymail.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/07 11:18:52 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: Simon South X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) This patch allows JamVM 2.0.0 to be built without using outdated versions of gcc and glibc, by disabling the branch-patching optimization JamVM normally applies to code it has inlined. I've successfully built IcedTea 1.13.13 on x86_64 with this patch applied, without encountering any "Invalid instruction" errors. It also seems to work fine on aarch64. Lengthy explanation, for anyone interested in the details: JamVM's branch-patching optimization tries to improve the performance of Java's branching opcodes by replacing the load-operand-and-jump portion of their implementation with a single jump instruction directly to the handler for the opcode to which the operand points. However, the current implementation - Doesn't attempt much of an optimization, since it only replaces the final jump instruction with another (the operand is still loaded in either case). - Doesn't have any actual effect since the instruction it replaces is a duplicate synthesized by gcc that is never executed anyway. - Is prone to breakage, since it doesn't ensure the new jump instruction is the same length as the original. (This is the specific reason for the failure on x86_64: The replacement jump instruction is longer and clobbers part of the following instruction, making it invalid.) This patch simply disables the optimization within JamVM, leaving the other optimizations intact. (gcc is smart enough to no longer generate duplicate jump instructions in this case so it reduces the code size slightly, too.) Alternate solutions I considered and rejected: - Fixing the implementation. JamVM uses a label to mark within each opcode's handler where the jump instruction should be placed, and moving this label to the start of the load-and-jump sequence rather than the end appears (from stepping through the code with gdb) to fix all the issues above. However, JamVM then fails at startup, reporting an unhandle-able exception during initialization. So presumably some other part of the code relies on the current, broken implementation of this feature, and while it's probably possible to fix _that_ as well I doubt it would be worth the effort. - Disabling the optimization at runtime. Invoking JamVM with "-Xnopatching" also solves the problem, and we could just update the bootstrap procedure to do this. However JamVM 1.5.1 doesn't recognize this option and fails if it's specified, so we'd need to change the ecj-javac-wrapper package to handle the two interpreters differently or to accept an argument specifying the flags to use, and in my opinion this would be a step backwards from what exists currently. Also, since JamVM would only ever work reliably when this option is specified, it's not really much of an "option" and making its effect permanent in the code seems like a more sensible approach. -- Simon South simon@simonsouth.net Simon South (1): gnu: jamvm: Fix to work with current gcc and glibc. gnu/packages/java.scm | 7 ++--- .../jamvm-2.0.0-disable-branch-patching.patch | 27 +++++++++++++++++++ 2 files changed, 29 insertions(+), 5 deletions(-) create mode 100644 gnu/packages/patches/jamvm-2.0.0-disable-branch-patching.patch -- 2.26.2