From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames. Date: Thu, 02 Aug 2012 08:12:29 +0400 Message-ID: <5019FE2D.2060005@yandex.ru> References: <50191B54.2070705@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1343880615 21903 80.91.229.3 (2 Aug 2012 04:10:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Aug 2012 04:10:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 02 06:10:15 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Swmjl-0003LO-H7 for ged-emacs-devel@m.gmane.org; Thu, 02 Aug 2012 06:10:13 +0200 Original-Received: from localhost ([::1]:36680 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swmjk-0007SR-L2 for ged-emacs-devel@m.gmane.org; Thu, 02 Aug 2012 00:10:12 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54884) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swmji-0007S9-Al for emacs-devel@gnu.org; Thu, 02 Aug 2012 00:10:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Swmjg-0007Wt-Sh for emacs-devel@gnu.org; Thu, 02 Aug 2012 00:10:10 -0400 Original-Received: from forward17.mail.yandex.net ([95.108.253.142]:57100) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swmjg-0007Ud-Be for emacs-devel@gnu.org; Thu, 02 Aug 2012 00:10:08 -0400 Original-Received: from smtp17.mail.yandex.net (smtp17.mail.yandex.net [95.108.252.17]) by forward17.mail.yandex.net (Yandex) with ESMTP id C0F71106189C; Thu, 2 Aug 2012 08:10:06 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1343880606; bh=nX4n5FigjdzREJqUfwAQC0Qcn5hZ3orQ788Tr6vSS3c=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=IN/GuiTpQWROY+qS815E7TbrZNLCQ0nAYexFjKYmrvOte10h8+0aUY2NtLfq2Hqwn 3v5AGP8szxNZ30ATqY7JJXYXqNuz8j2HQCNlysELutVAk8GBZG7FlcK+CdRl21O58U nuNY87sPuULK5rb56fbWoKVdQJAbDCTvrOL8mJWY= Original-Received: from smtp17.mail.yandex.net (localhost [127.0.0.1]) by smtp17.mail.yandex.net (Yandex) with ESMTP id 823531900553; Thu, 2 Aug 2012 08:10:06 +0400 (MSK) Original-Received: from 80.gprs.mts.ru (80.gprs.mts.ru [213.87.134.80]) by smtp17.mail.yandex.net (nwsmtp/Yandex) with ESMTP id A4S4UDHe-A5SGuhsI; Thu, 2 Aug 2012 08:10:06 +0400 X-Yandex-Rcpt-Suid: monnier@IRO.UMontreal.CA X-Yandex-Rcpt-Suid: emacs-devel@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1343880606; bh=nX4n5FigjdzREJqUfwAQC0Qcn5hZ3orQ788Tr6vSS3c=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=e2JSuChupMLngmmi/ihQK8pI4NCtosQfm0JWwYyipWyN7guM+ZZ3g3roX/TTRk2pK 1705LR5N1GOGEWpAr3G3GtbIvcnadP14zQke96R38Wa/j7yqRnoBsr47bP7ZWbdFPB VrvZlLKIg4SyVciZ5KShFtGHvoxiyzOXkDkhDh6U= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 95.108.253.142 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:152103 Archived-At: On 08/02/2012 03:52 AM, Stefan Monnier wrote: > Then, please undo your changes. The INTERNAL_FIELD part is fine, but > the new FVAR, WVAR, ... are not. Maybe it can be useful as an > intermediate step on some separate generational-gc branch, but it > doesn't have its place in trunk: Look at concurrency branch. Everyone agrees that this is an interesting and useful feature, but no one wants to handle an endless merging efforts. If we had the same amount of developers as involved in Linux kernel, it's the only possible practice to maintain 100 branches or even separate trees for each major feature; for us, everything which is not in trunk is the candidate to throw and forget, and large amount of code increases the probability of such an inglorious end. > I can't think of any way to make such > macros give realistic performance with anything but a write-barrier, so > such macros will only ever be needed for write accesses and never for > read-accesses. > So you're obfuscating the read-accesses (i.e. the most common case) for > no good reason. > I'm OK with introducing such macros to *set* such fields (i.e. for write > barriers), but not to read them (at least not until there's a really > good case for them). Really good case comes very quickly when you start the real debugging. Things like FVAR are very helpful to trace _all_ accesses to Lisp_Object members; when FVARs will be converted to rvalues and SETFVARs will be used appropriately, this guarantees that no pointer stores bypasses the barrier (just one such a store is fatal for the collector). Next, when we will know that the collector invariant is never broken, it's possible to replace these obfuscated FVAR (x, y) back to x->y. Again, this is a kind of chicken-egg problem: it's very hard to design GC bits without supporting infrastructure implemented, and no one wants to deal with obfuscated internal things in the absence of visible advantages provided by new GC. IMHO the only solution is to suffer some obfuscation until it becomes really useful. Dmitry