Types of malloc in ATS

Google Group
1

Memory allocated by malloc_linear can be freed or leaked
(that, turning into something non-linear).

So even if there is no malloc_nonlinear in a program, it does
not imply that the program cannot cause leaks.

For instance, calling functions like list_of_list_vt (for turning
a linear list into a non-linear one) leaks memory.

The truth is that there is really no malloc_nonlinear.
For instance, we studied this issue in the following paper:

http://www.cs.bu.edu/~hwxi/academic/papers/ictac10.pdfOn Sunday, November 16, 2014 10:48:22 PM UTC-5, Barry Schwartz wrote:

I have been thinking about the role of what I will call ‘malloc’ in
ATS.

While having ‘malloc_nonlinear’ and ‘malloc_linear’ would be indeed
quite ad hoc, I think what amounts to the same thing by different
names is less so. Certainly to me (as a Schemer, albeit not an
addicted one) it makes at least as much sense as having to have
special notations for tail calls (‘and’, ‘fnx’).

My point is that calling an allocator with the intention of having
that call ‘bracketed’ by a free is different from calling an allocator
without the intention of having that call ‘bracketed’ by a free. There
is a philosophical difference. So perhaps it deserves a hint or at
least a ‘philosophical distiction’ by having slightly different names
(at the #define level) for the two types of call; not
nonlinear-vs-linear, which is an ad hoc distinction, but ‘free is
expected’ versus ‘free is not expected’.

OTOH I’m still not convinced that ‘boolean’ should be a separate type
(in general) from modulo-2 arithmetic, so I don’t know. :slight_smile:

2

For what it is worth, the compiler now adds the following
comment before the code that creates a nonlinear contructor:

/*
lincon==0
*/

For a linear constructor, the comment reads:

/*
lincon==1
*/On Tuesday, November 18, 2014 3:45:12 PM UTC-5, Barry Schwartz wrote:

gmhwxi <gmh...@gmail.com <javascript:>> skribis:

Memory allocated by malloc_linear can be freed or leaked
(that, turning into something non-linear).

So even if there is no malloc_nonlinear in a program, it does
not imply that the program cannot cause leaks.

That is why I wrote in terms of general intentions. Similar to using
macro wrappers that do nothing but which document some mental
distinction, and perhaps could be used at some future date to give
hints to the machine. Or like the GCC attribute for ‘maybe unused’
that doesn’t mean the variable is unused, but turns off warnings if
it happens to be. Or like in the Guile API, which has
scm_gc_protect_object, scm_gc_unprotect_object, and
scm_permanent_object, to control garbage collection; the last is
implemented as a wrapper around the first, and so actually the
‘permanent’ object could be ‘unprotected’; however, the
implementation could be different, and in any case the call has a
vaguely different meaning to humans.

But, as I say, I don’t know. Drawing distinctions is fraught with
peril, just as glossing them over is.

3

For the record, the comment now reads:

/*
#LINCONSTATUS==i
*/

where

i=0 implies linear constructor
i=1 implies nonlinear constructor
i=2 implies nonlinear record

So if you find #LINCONSTATUS==i for a positive integer i, then it is
a strong indication of potential leak. Note that leaks are still possible
even if you only see #LINCONSTATUS==0.On Tuesday, November 18, 2014 5:14:38 PM UTC-5, Barry Schwartz wrote:

gmhwxi <gmh...@gmail.com <javascript:>> skribis:

For what it is worth, the compiler now adds the following
comment before the code that creates a nonlinear contructor:

/*
lincon==0
*/

For a linear constructor, the comment reads:

/*
lincon==1
*/

Definitely safely harmless. :slight_smile: And easily grepped.

4

choice quote.