From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.bugs Subject: bug#41242: Port feature/native-comp to Windows Date: Thu, 14 May 2020 17:34:36 +0000 Message-ID: References: <834ksi60zn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="86730"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: 41242@debbugs.gnu.org To: Nicolas =?UTF-8?Q?B=C3=A9rtolo?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 14 19:35:11 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jZHlG-000MT8-Op for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 May 2020 19:35:10 +0200 Original-Received: from localhost ([::1]:50252 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZHlF-0003WZ-RB for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 May 2020 13:35:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZHl8-0003Uq-No for bug-gnu-emacs@gnu.org; Thu, 14 May 2020 13:35:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51395) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jZHl8-0007UC-C8 for bug-gnu-emacs@gnu.org; Thu, 14 May 2020 13:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jZHl8-0004bL-8q for bug-gnu-emacs@gnu.org; Thu, 14 May 2020 13:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2020 17:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41242 X-GNU-PR-Package: emacs Original-Received: via spool by 41242-submit@debbugs.gnu.org id=B41242.158947768017651 (code B ref 41242); Thu, 14 May 2020 17:35:02 +0000 Original-Received: (at 41242) by debbugs.gnu.org; 14 May 2020 17:34:40 +0000 Original-Received: from localhost ([127.0.0.1]:34708 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZHkl-0004ad-SS for submit@debbugs.gnu.org; Thu, 14 May 2020 13:34:40 -0400 Original-Received: from mx.sdf.org ([205.166.94.20]:54844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZHkj-0004aU-Ht for 41242@debbugs.gnu.org; Thu, 14 May 2020 13:34:38 -0400 Original-Received: from sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 04EHYaX3011542 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 14 May 2020 17:34:36 GMT Original-Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 04EHYaXs011032; Thu, 14 May 2020 17:34:36 GMT In-Reply-To: ("Nicolas =?UTF-8?Q?B=C3=A9rtolo?="'s message of "Thu, 14 May 2020 13:50:48 -0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:180228 Archived-At: Nicolas B=C3=A9rtolo writes: >> Loading a new compilation unit B that redefines the same functions >> defined by A does not guarantees much, some of the old definitions of A >> could be still in use somewhere, in that case A will not be collected. > >> So yeah I think we need a specific mechanism (kill-emacs hook as you >> suggest) to do the cleanup when Emacs goes down. > > I was thinking about something like this: > > 1) Call `native-comp-unload`. > > 2) This should inspect the eln file and put all the subrs defined in it o= n a > list. This should also copy the original bytecode from the eln file and s= tore it > somewhere. > > 3) Then `garbage-collect` is called. This should find all references to t= he > subrs in the list and swap them atomically for references to functions > from the bytecode. > > 4) After the previous step the GC should be able to collect the DLL handle > knowing that no references to it remain. > > What do you think? It can't work for the following reasons: 1- eln files do not retain the orginal function bytecode. 2- in any point of the code you can get the symbol-function of a defined function and leak it everywhere. We can't technically "swap" functions definitions, the best we do is just redefine them that is set a certain symbol-function (what late load does). The old definitions can always still be used if the referennce is still present somewhere. Even worst the function you want to remove could be active in the stack! One option would be to add a field into the compilation unit object like 'pending_for_removal', each time any of this is unloaded by GC the file is removed if the field suggests that. At the very last when Emacs is closing we go through all the compilation units and remove the files that are still pending. >> No you are right, I don't use Windows since forever, I discovered from >> this thread is not portable. I guess we'll need to rename also here. > > But someone needs to delete the old eln file. Let's say that we use > GetModuleFileNameA() to know if another Emacs instance has decided to ren= ame the > eln file and then we delete it on close if its suffix is ".eln.old". > > This algorithm has a big race condition though. If Emacs1 renames the fil= e after > Emacs2 has checked that it has not been renamed, then the file won't be d= eleted. > If we put the "old eln" in the $TEMP folder this may not be a big issue t= hough. Yes renaming for me here was moving into a temporary folder. This could be a very simple option also for the first problem if we accept we can leave some file there from time to time. Andrea --=20 akrl@sdf.org