From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26703 invoked by alias); 12 Jul 2015 20:16:15 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 26683 invoked by uid 89); 12 Jul 2015 20:16:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.98.7 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients X-HELO: paperclip.tbsaunde.org Date: Thu, 01 Jan 2015 00:00:00 -0000 From: Trevor Saunders To: Jeff Law Cc: Armin Rigo , David Malcolm , Basile Starynkevitch , jit@gcc.gnu.org, GCC Development Subject: Re: GCC/JIT and precise garbage collection support? Message-ID: <20150712201542.GA6858@tsaunders-iceball.corp.tor1.mozilla.com> References: <559EF2F1.6000000@starynkevitch.net> <1436493224.31573.32.camel@surprise> <1436537517.31573.48.camel@surprise> <55A01062.8000301@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A01062.8000301@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-q3/txt/msg00084.txt.bz2 On Fri, Jul 10, 2015 at 12:35:14PM -0600, Jeff Law wrote: > On 07/10/2015 09:04 AM, Armin Rigo wrote: > >Hi David, > > > >On 10 July 2015 at 16:11, David Malcolm wrote: > >>AIUI, we have CALL_INSN instructions all the way through the RTL phase > >>of the backend, so we can identify which locations in the generated code > >>are calls; presumably we'd need at each CALL_INSN to determine somehow > >>which RTL expressions tagged as being GC-aware are live (perhaps a > >>mixture of registers and fp-offset expressions?) > >> > >>So presumably we could use that information (maybe in the final pass) to > >>write out some metadata describing for each %pc callsite the relevant GC > >>roots. > >> > >>Armin: does this sound like what you need? > > > >Not quite. I can understand that you're trying to find some solution > >with automatic discovery of the live variables of a "GC pointer" type > >and so on. This is more than we need, and if > >we had that, then we'd need to work harder to remove the extra stuff. > >We only want the end result: attach to each CALL_INSN a list of > >variables which should be stored in the stack map for that call, and > >be ready to see these locations be modified from outside across the > >call if a GC occurs. > I wonder how much overlap there is between this need and what we're going to > need to do for resumable functions which are being discussed in the ISO C++ I'm not sure about that, but there may also be some overlap with the machinary to handle exceptions. It sounded kind of crazy and I'm not sure what happened to it, but a while ago at Mozilla someone was proposing to use eh tables to implement rootting in the JS gc. Trev > standards meetings. > > jeff