From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69410 invoked by alias); 10 Jul 2015 08:41:02 -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 69385 invoked by uid 89); 10 Jul 2015 08:41:02 -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=-2.0 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no 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: mx1.redhat.com Message-ID: <559F8519.6000107@redhat.com> Date: Thu, 01 Jan 2015 00:00:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Basile Starynkevitch , jit@gcc.gnu.org CC: gcc@gcc.gnu.org Subject: Re: GCC/JIT and precise garbage collection support? References: <559EF2F1.6000000@starynkevitch.net> In-Reply-To: <559EF2F1.6000000@starynkevitch.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-SW-Source: 2015-q3/txt/msg00075.txt.bz2 On 09/07/15 23:17, Basile Starynkevitch wrote: > (this is triggered by a question on the Ocaml mailing list asking about > SystemZ backend in Ocaml; SystemZ is today a backend for GCC & probably > GCCJIT) > > We might want to support better good garbage collection schemes in GCC, > particularily in GCCJIT. This is a > thing that LLVM is known to be weak at, and we might aim to do much > better. If we did, good frontends for > good functional languages (e.g. F#, Ocaml, Haskell) might in the future > profit of GCC technology. And even a Javascript engine based on GCCJIT > could profit. > > A good GC is very probably a precise (sometimes generational copying) GC > with write barriers > (read the http://gchandbook.org/ for more, or at least the wikipage > about garbage collection). So a good GC is changing pointers. > > So we need to know where, and provide a mechanism for, pointer values > are located in the call stack (of the GCCJIT generated code), and > probably provide some write barrier machinery. It's going to be very hard. All our experience with GCJ shows that a true precise GC in GCC is going to require major surgery in many places. The HotSpot optimizing compilers are written with GC as a basic requirement and it touches many places. Andrew.