From xen-devel-bounces@lists.xen.org Thu Feb 18 17:50:29 2016 Received: (at maildrop) by bugs.xenproject.org; 18 Feb 2016 17:50:29 +0000 Received: from lists.xenproject.org ([50.57.142.19] helo=lists.xen.org) by bugs.xenproject.org with esmtp (Exim 4.80) (envelope-from ) id 1aWSij-0008Nf-OY for xen-devel-maildrop-Eithu9ie@bugs.xenproject.org; Thu, 18 Feb 2016 17:50:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aWSgJ-0005uR-D6; Thu, 18 Feb 2016 17:47:59 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aWSgH-0005uM-F5 for xen-devel@lists.xen.org; Thu, 18 Feb 2016 17:47:57 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id D8/7E-12889-CC306C65; Thu, 18 Feb 2016 17:47:56 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1455817674!24970597!1 X-Originating-IP: [209.85.214.171] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 64235 invoked from network); 18 Feb 2016 17:47:55 -0000 Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by server-10.tower-27.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 18 Feb 2016 17:47:55 -0000 Received: by mail-ob0-f171.google.com with SMTP id p4so1140702obl.1 for ; Thu, 18 Feb 2016 09:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4OwZ/JhgdGi/llbNq2X52dTWBMh298pFbVhbnwVJ52M=; b=gEoZ7y26245oXAs3qnKmXu2pYSxvH2gwNAZf443eZBikNoj0Xr+XkqciVC6U06unE6 wRHeRPv1ZEqzdhFLrNkeWt+OmPgBmtmIruF//5T4MiFspquH2n+jilFb7nsls1cxdcE8 01keAoMcF+1K/T/o+Avr7ByFeMHuH8f6w3SkgFkDTVBKRqUSCsEi7Mc0gRdy744ULtZ8 N0adyZP3PMsgv83rnwGT8c2gWuBNOy1OE9GYOtt/xx6SJh9iooPAvqDXDIWZL1NvHHOr xDNOXLZCdfGtBCzdt4G0gxxnefOQEG+GEw16AWSxhFjPAOk+Q9t9qZx0UeJ/TypyP74/ NoUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4OwZ/JhgdGi/llbNq2X52dTWBMh298pFbVhbnwVJ52M=; b=aH2zC+vwBDoGfT0yR4x9JRVHZgQBqSPXlq50ruQ0069gQSh6/Ht9RsJRA5cYSL+m0p ydPN/pTEw1NCBn43sKQNRfDLaOR5wKeE62UI26tbOzWUyeQzwW3iXhqvuVVPlFHj5OYs aQ14g/ars5YnSfqIP7OcWGH7OH95FdqkaD61OUXGVpExoCL5900VDNZ/FprPY2TSOAHU It6yVoWhF8+2Rq94BdeFU/gxtCvacUORni0sJy7vAi7p1LB0c9nR7TUyAW1YT7gn4JSW bFd6GdTsJbanVb+JwGRNLZcqhxdInVBciHurdHc2fj3IWdtE4xG53Arj5kZQBrngGuRo ga9g== X-Gm-Message-State: AG10YOStQX2Y7cCNNWdjuaA5GX513QgWjpiOoVdL4ZnvKt0qBlIyQzlDWS+nmHN1jmdZma9QRMkfWEzklyv+JA== MIME-Version: 1.0 X-Received: by 10.182.102.103 with SMTP id fn7mr7733203obb.83.1455817673585; Thu, 18 Feb 2016 09:47:53 -0800 (PST) Received: by 10.202.205.140 with HTTP; Thu, 18 Feb 2016 09:47:53 -0800 (PST) In-Reply-To: <1455817167.6225.65.camel@citrix.com> References: <564CC43B.1000904@ainfosec.com> <1447924858.5647.15.camel@citrix.com> <564DAA8D.5060305@citrix.com> <1447932195.5647.46.camel@citrix.com> <1455817167.6225.65.camel@citrix.com> Date: Thu, 18 Feb 2016 17:47:53 +0000 X-Google-Sender-Auth: Pl06EWNzJK2RHN0j6EZ_sSOJNos Message-ID: From: George Dunlap To: Ian Campbell Cc: Andrew Cooper , "xen-devel@lists.xen.org" , Martin Osterloh , Jonathan Ludlam , Rob Hoes Subject: Re: [Xen-devel] Current LibXL Status X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org On Thu, Feb 18, 2016 at 5:39 PM, Ian Campbell wrote: > On Thu, 2016-02-18 at 17:26 +0000, George Dunlap wrote: > >> According to them, the ocaml garbage collector never frees memory. It >> grows its own internal heap as necessary, but it never reduces the >> size of its heap. > > Assume that's true: Wow! > > Although, I presume this is a factor of the current/particular > implementation, rather than a fundamental property of an ocaml runtime, so > in theory it could change (and we have here a good real world argument why > it perhaps should do!) > >> So no -ENOMEM call or OOM callback can make a failed malloc succeed. >> >> One might then ask if libxl could simply allocate memory *from the >> ocaml heap* itself. It turns out that is also not tenable: Data in >> the ocaml heap is stored in a heavily coded format. (For example >> integers are stored as (n*2+1), so that pointers can all be even and >> non-pointers can all be odd.) >> >> The only thing they said might be improved is: >> >> 1. To know that libxl would never call exit() for any other reason >> (which it seems is true) >> >> 2. To have a callback in OOM conditions. It's unlikely the process >> as a whole could do anything but exit, but the ocaml runtime itself >> might still have internal heap available, which would allow it to exit >> more gracefully. >> >> I think if Haskell or any library *is* capable of integrating with the >> garbage collector, we'll have to wait until someone who understands >> the language actually writes bindings and can ask for something they >> know to be useful for that language. > > Agreed. > > Hopefully it is possible to make the callback without needing to malloc > anything! > > If I were adding an API for #2 to libxl (which must therefore be stable) I > think I might be inclined to allow for the possibility of the callback > returning "please retry" since it would be inconvenient in the usual API > stability ways to retrofit it, I would guess, but really until a language > even exposes that possibility we don't really know if it is worthwhile > doing so. Well we could just make the semantics such that if the callback returns at all, that libxl should retry. That shouldn't be particularly harder than just making a callback we don't expect to ever return (which is what it sounds like the xapi folks would be happy with). Then when we come across a language runtime / application that *can* do something useful, it might possibly Just Work; but if it doesn't we can implement what they actually need. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel