WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] [PATCH] document xl memory management policy

To: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH] document xl memory management policy
From: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
Date: Fri, 13 Aug 2010 16:36:17 +0100
Cc: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Fri, 13 Aug 2010 08:41:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
After animated discussion with several libxl developers we seem to have
agreed on a policy for memory management within libxenlight. These
comments document the policy which is mostly implemented since
21977:51147d5b17c3 but some aspects (comments, function naming) are
guidelines to be followed in future functionality and perhaps to be
implemented by search/replace in future patches.

The document is mostly authored by Ian Jackson but with modifications to
reflect the slightly different functionality that has been implemented
since this was proposed.

Signed-off-by: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>

diff -r 85bd0f6e8fed tools/libxl/libxl.h
--- a/tools/libxl/libxl.h       Fri Aug 13 13:55:51 2010 +0100
+++ b/tools/libxl/libxl.h       Fri Aug 13 16:33:23 2010 +0100
@@ -12,6 +12,116 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU Lesser General Public License for more details.
  */
+
+/*
+ * libxl memory management
+ *
+ * From the point of view of the application (ie, libxl's caller),
+ * struct libxl_ctx* is threadsafe, and all returned allocated
+ * structures are obtained from malloc(), and must be freed by the
+ * caller either directly or by calling an appropriate free function
+ * provided by libxl.  Ie the application does not get automatic
+ * assistance from libxl in managing these allocations.
+ *
+ * Specific details are in the header comments which should be found
+ * in libxl.h or libxlutil.h, next to the relevant function
+ * declarations.
+ *
+ * Internally, libxl has a garbage collection scheme which allows much libxl
+ * code to allocate strings etc. for internal use without needing to
+ * free them.  These are called "temporary allocations".
+ *
+ * The pool for these temporary allocations, along with any other
+ * thread-specific data which is private to libxl but shared between
+ * libxl functions (such as the current xenstore transaction), is
+ * stored in the "gc context" which is a special enhanced context
+ * structure allocated automatically by convenience macros at every
+ * entry to libxl.
+ *
+ * Every libxl function falls into one of these categories:
+ *
+ * 1. Public functions (declared in libxl.h, libxlutil.h), which may
+ *    be called by libxl applications.  If a public function returns
+ *    any allocated object to its caller, that object must have come
+ *    from malloc.
+ *
+ *    The definitions of public functions MUST use the gc context
+ *    initialisation macros (or do the equivalent work themselves).
+ *    These macros will ensure that all temporary allocations will be
+ *    automatically freed before the function returns to its caller.
+ *
+ *    A public function may be called from within libxl; the call
+ *    context initialisation macros will make sure that the internal
+ *    caller's context is reused (eg, so that the same xenstore
+ *    transaction is used).
+ *
+ *    Public functions have names like libxl_foobar.
+ *
+ * 2. Private functions, which may not be called by libxl
+ *    applications; they are not declared in libxl.h or libxlutil.h
+ *    and they may not be called other than by other libxl functions.
+ *
+ *    Private functions should not use the gc context initialisation
+ *    macros.
+ *
+ *    Private functions have names like libxl__foobar (NB, two underscores).
+ *    Also the declaration of such functions must be preceeded by the _hidden
+ *    macro.
+ *
+ * Allocations made by a libxl function fall into one of the following
+ * categories (where "object" includes any memory allocation):
+ *
+ * (a) Objects which are not returned to the function's caller.
+ *     These should be allocated from the temporary pool.
+ *
+ * (b) Objects which are intended for return to the calling
+ *     application.  This includes all allocated objects returned by
+ *     any public function.
+ *
+ *     It may also include objects allocated by an internal function
+ *     specifically for eventual return by the function's external
+ *     callers, but this situation should be clearly documented in
+ *     comments.
+ *
+ *     These should be allocated from malloc() et al. and comments
+ *     near the function declaration should explain the memory
+ *     ownership.  If a simple free() by the application is not
+ *     sufficient, a suitable public freeing function should be
+ *     provided.
+ *
+ * (c) Internal objects whose size and/or lifetime dictate explicit
+ *     memory management within libxl.  This includes objects which
+ *     will be embedded in opaque structures which will be returned to
+ *     the libxl caller (more generally, any internal object whose
+ *     lifetime exceeds the libxl entrypoint which creates it) and
+ *     objects which are so large or numerous that explicit memory
+ *     management is required.
+ *
+ *     These should be allocated from malloc() et al., and freed
+ *     explicitly at the appropriate point.  The situation should be
+ *     documented in comments.
+ *
+ * (d) Objects which are allocated by internal-only functions and
+ *     returned to the function's (therefore, internal) caller but are
+ *     strictly for internal use by other parts of libxl.  These
+ *     should be allocated from the temporary pool.
+ *
+ *     Where a function's primary purpose is to return such an object,
+ *     it should have a libxl_gc * as it's first argument.
+ *
+ *     Note that there are two ways to change an allocation from this
+ *     category to the "public" category. Either the implementation
+ *     is kept internal and a wrapper function duplicates all memory
+ *     allocations so that they are suitable for return to external
+ *     callers or the implementation uses plain malloc() et al calls
+ *     and an internal wrapper adds the relevant pointers to the gc.
+ *     The latter method is preferred for obvious performance reasons.
+ *
+ * No temporary objects allocated from the pool should be explicitly freed.
+ * Calling libxl_free_all() before returning from a public functions will do
+ * this. The upshot of this is that almost all calls to libxl_free() are
+ * erroneous.
+ */
 #ifndef LIBXL_H
 #define LIBXL_H
 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] [PATCH] document xl memory management policy, Gianni Tedesco <=