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: GC and stack marking Date: Wed, 21 May 2014 19:57:42 +0400 Message-ID: <537CCCF6.6020509@yandex.ru> References: <83a9add91p.fsf@gnu.org> <8338g4bd7m.fsf@gnu.org> <83wqdgntan.fsf@gnu.org> <83ppj7oniv.fsf@gnu.org> <838upvnnsq.fsf@gnu.org> 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: ger.gmane.org 1400687904 32336 80.91.229.3 (21 May 2014 15:58:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 21 May 2014 15:58:24 +0000 (UTC) Cc: fabrice.popineau@gmail.com, Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 21 17:58:18 2014 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 1Wn8uH-0006Hc-Du for ged-emacs-devel@m.gmane.org; Wed, 21 May 2014 17:58:17 +0200 Original-Received: from localhost ([::1]:60511 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn8uG-0007yj-Vv for ged-emacs-devel@m.gmane.org; Wed, 21 May 2014 11:58:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn8u8-0007yS-Pg for emacs-devel@gnu.org; Wed, 21 May 2014 11:58:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wn8u2-0007g8-PO for emacs-devel@gnu.org; Wed, 21 May 2014 11:58:08 -0400 Original-Received: from forward6l.mail.yandex.net ([84.201.143.139]:59732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wn8tw-0007eW-1Y; Wed, 21 May 2014 11:57:56 -0400 Original-Received: from smtp8.mail.yandex.net (smtp8.mail.yandex.net [77.88.61.54]) by forward6l.mail.yandex.net (Yandex) with ESMTP id 1614E14E165C; Wed, 21 May 2014 19:57:43 +0400 (MSK) Original-Received: from smtp8.mail.yandex.net (localhost [127.0.0.1]) by smtp8.mail.yandex.net (Yandex) with ESMTP id 8EA9B1B600C4; Wed, 21 May 2014 19:57:42 +0400 (MSK) Original-Received: from unknown (unknown [37.139.80.10]) by smtp8.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id gounm71Nec-vgp8K2c8; Wed, 21 May 2014 19:57:42 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 9c0f7b52-00a8-489b-a5d9-c3dd1c7dbf1c DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1400687862; bh=6c3oZR1O7OEWeHVHvd3M0rTNYrQX0vmLVC2030gh2vM=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=PAR9otJoaOhrDW5nFusjtkfuUQLxJjItRbeC5V5v01OXv9LnnyrUwAQUE1i1cmVks BzyDmuzQyI/vHeya2Gw9cT4Bw1xTLyLfPoqnSkV6eHu5DwMJoqfBW3BDjonQ7EHRyu gjCzdW2kJ1rHOAWHRMCjjAczpxdXGnAOWSEqTlc4= Authentication-Results: smtp8.mail.yandex.net; dkim=pass header.i=@yandex.ru User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <838upvnnsq.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 84.201.143.139 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:171993 Archived-At: On 05/21/2014 07:39 PM, Eli Zaretskii wrote: > Now, I have a question: mark_stack stops examining the stack when it > gets to its own stack frame. That is certainly safe, but it sounds > too conservative: it should stop at the stack frame of > Fgarbage_collect, I think, because no live Lisp object can appear > while Fgarbage_collect runs, right? 1) Yes, but you need ABI- and machine-specific tricks to find the stack frame boundaries. I.e. while in mark_stack, there is no easy way to find start and end of Fgarbage_collect's stack frame. 2) But see GCC's __builtin_frame_address, https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html. 3) But even if 2) works on all platforms we have to support, I don't see a reasons to complicate GC just to avoid scanning a few tens of bytes of an extra stack frame. Dmitry