From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id B48C4BBC4 for ; Sun, 8 Mar 2009 02:13:51 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIBAOOqsknUnwckjmdsb2JhbACCHZMFAQEBAQkLCAkPBr1NhAUG X-IronPort-AV: E=Sophos;i="4.38,321,1233529200"; d="scan'208";a="22205377" Received: from relay.ptn-ipout02.plus.net ([212.159.7.36]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Mar 2009 02:13:51 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIEAOOqsknUnw6T/2dsb2JhbACCHdEQhAUG Received: from ptb-relay03.plus.net ([212.159.14.147]) by relay.ptn-ipout02.plus.net with ESMTP; 08 Mar 2009 01:13:51 +0000 Received: from [87.112.234.120] (helo=leper.local) by ptb-relay03.plus.net with esmtp (Exim) id 1Lg7aR-0001pP-2S for caml-list@yquem.inria.fr; Sun, 08 Mar 2009 01:13:51 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: HLVM is now garbage collected! Date: Sun, 8 Mar 2009 01:19:20 +0000 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200903080119.20330.jon@ffconsultancy.com> X-Plusnet-Relay: a19626a8c30218f61e67e1b40c8e69cd X-Spam: no; 0.00; pointers:01 recursive:01 ocaml:01 frog:98 garbage:01 overflows:01 stack:01 stack:01 heap:01 heap:01 tail:01 linear:02 defined:02 roots:02 allocated:02 Well, I have my first working GC running in HLVM now! Woohoo! The implementation has some interesting properties: . The GC is written entirely in HLVM's own intermediate language. . When a new type is defined a new function to traverse that type is JIT compiled. So code for the GC is generated on-the-fly. . The GC is very simple and uses a shadow stack to track roots and an allocated list that stores all heap allocated locations and their mark bit. . When the GC gets involved, performance is currently awful. Two simple optimizations will go a long way to curing this: touch the shadow stack only when necessary, and do something cleverer than the current linear lookup (!) of allocated pointers in the GC. . When the heap is deep the current GC stack overflows because it is not tail recursive. This is easily fixed. I have applied to the OCaml Forge to create a new project for HLVM where I will upload my initial prototype. Just as soon as my French gets good enough to understand this automated e-mail... ;-) -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e