Meaning, if I am not linking a library with malloc and free I can’t accidentally use it, and if I do have a library, I can’t accidentally produce a leak?
For example, the function example sqrmodsum in the text: does it produce an error when malloc is not available, and if available, does this example leak? Or does it make one heap object that is reused on each call?
I guess I want to know under what circumstances a nieve maintainer can get into trouble. My hope is the behavior is either fail to compile, or no leak. If I am correct, then in which ways can I create a closure that leaks so I can r cognizant them?
The annotation ‘’ means that IF the function is passed as an
argument
(to another function), then a closure is formed. If the function is never
passed as
an argument, there is no closure formation.
This code is of ATS1-style. I think ‘’ can be erased here without
causing
any problems.On Tuesday, December 29, 2015 at 1:21:21 PM UTC-5, Mike Jones wrote:
There is another closure example in the introduction book I want to
understand. Section 6.5 has code below.
The fun definitions have , and do not follow the typical syntax
of a value bound to a lam. So does this mean a closure is returned? Does it
mean the fun is a closure? Is any thing on the heap? And what is the
purpose of it in this example?
fun{
a:t@ype
} insertion_sort
(
A: arrszref (a)
, cmp: (a, a) → int
) : void = let
val n = g0uint2int_size_int(A.size())
fun ins (x: a, i: int): void =
if i >= 0 then
(
if cmp (x, A[i]) < 0
then (A[i+1] := A[i]; ins (x, i-1)) else A[i+1] := x
// end of [if]
) else A[0] := x // end of [if]
// end of [ins]
fun loop (i: int): void =
if i < n then (ins (A[i], i-1); loop (i+1)) else ()
To use malloc, you need to compile with a flag looking like
-DATS_MEMALLOC_???
For instance,
patscc -DATS_MEMALLOC_LIBC -o foo foo.dats // using malloc/free in libc
patscc -DATS_MEMALLOC_GCBDW -o foo foo.dats -lgc // using Bohem GC
If you use malloc but do not use -DATS_MEMALLOC_???, then you will see
the following error message issued by the linker:
undefined reference to `atsruntime_malloc_undef’
If you can compile your ATS code to executable without using
-DATS_MEMALLOC_???,
then your ATS code cannot generate memory leaks (because it does not even
call malloc).
On Tue, Dec 29, 2015 at 9:56 AM, Mike jones <proc…> wrote:
I assume that if there is no alloc/malloc library to link, there cannot
be links, because I kind of remember that for ATS the GC operates via this
API. I would like to confirm that.
The danger for me is my application layers on ThreadX, wrappers by
Cypress, but I think it exposes the alloc/malloc. Would a simple search of
the generated C be enough to determine no leaks? Or are there other calls I
need to check?
Sent from my iPad
On Dec 28, 2015, at 5:30 PM, gmhwxi <gm…> wrote:
To recognize whether the C code generated from ATS source
does something bad (e.g., leaks memory), one needs to analyze the
C code. Tools need to be developed for doing such analysis.
On Monday, December 28, 2015 at 7:28:14 PM UTC-5, gmhwxi wrote:
In general, malloc needs to be called to construct a closure.
However, ‘free’ is not called automatically. If you use a linear
closure (cloptr) but do not call ‘free’, you will get a type-error
somewhere.
If you use a persistent closure (cloref), you can not free the closure
explicitly
(in a type-safe manner). Instead, GC is needed to reclaim the closure.
In other words, if you create a cloref but do not run GC, you have a
potential
memory leak.
On Monday, December 28, 2015 at 5:13:53 PM UTC-5, Mike Jones wrote:
Ref 3.13 of Introduction, ifold2…
Do closures of in general:
Gen code with a malloc call?
Gen code with free after exiting scope?
Meaning, if I am not linking a library with malloc and free I can’t
accidentally use it, and if I do have a library, I can’t accidentally
produce a leak?
For example, the function example sqrmodsum in the text: does it
produce an error when malloc is not available, and if available, does this
example leak? Or does it make one heap object that is reused on each call?
I guess I want to know under what circumstances a nieve maintainer can
get into trouble. My hope is the behavior is either fail to compile, or no
leak. If I am correct, then in which ways can I create a closure that leaks
so I can r cognizant them?
In general, malloc needs to be called to construct a closure.
However, ‘free’ is not called automatically. If you use a linear
closure (cloptr) but do not call ‘free’, you will get a type-error
somewhere.
If you use a persistent closure (cloref), you can not free the closure
explicitly
(in a type-safe manner). Instead, GC is needed to reclaim the closure.
In other words, if you create a cloref but do not run GC, you have a
potential
memory leak.On Monday, December 28, 2015 at 5:13:53 PM UTC-5, Mike Jones wrote:
Ref 3.13 of Introduction, ifold2…
Do closures of in general:
Gen code with a malloc call?
Gen code with free after exiting scope?
Meaning, if I am not linking a library with malloc and free I can’t
accidentally use it, and if I do have a library, I can’t accidentally
produce a leak?
For example, the function example sqrmodsum in the text: does it produce
an error when malloc is not available, and if available, does this example
leak? Or does it make one heap object that is reused on each call?
I guess I want to know under what circumstances a nieve maintainer can get
into trouble. My hope is the behavior is either fail to compile, or no
leak. If I am correct, then in which ways can I create a closure that leaks
so I can r cognizant them?
This shows how to put it on heap/GC, and stack, how do you put it in static memory? I assume you create a standard function or instantiated template. Then do you have to cast it?
Meaning, if I am not linking a library with malloc and free I can’t
accidentally use it, and if I do have a library, I can’t accidentally
produce a leak?
To recognize whether the C code generated from ATS source
does something bad (e.g., leaks memory), one needs to analyze the
C code. Tools need to be developed for doing such analysis.
I can’t find back the thread, I just remember exceptions may produce memory
leaks too.
Note that this is static allocation; it is not done by alloca.On Monday, December 28, 2015 at 5:20:04 PM UTC-5, Mike Jones wrote:
A related question is why wouldn’t the example sqrmodsum put the closure
on the stack? It is not needed outside the scope of this function as it is
not in any way returned, and there is no lazy evaluation.
A related question is why wouldn’t the example sqrmodsum put the closure on the stack? It is not needed outside the scope of this function as it is not in any way returned, and there is no lazy evaluation.
To recognize whether the C code generated from ATS source
does something bad (e.g., leaks memory), one needs to analyze the
C code. Tools need to be developed for doing such analysis.On Monday, December 28, 2015 at 7:28:14 PM UTC-5, gmhwxi wrote:
In general, malloc needs to be called to construct a closure.
However, ‘free’ is not called automatically. If you use a linear
closure (cloptr) but do not call ‘free’, you will get a type-error
somewhere.
If you use a persistent closure (cloref), you can not free the closure
explicitly
(in a type-safe manner). Instead, GC is needed to reclaim the closure.
In other words, if you create a cloref but do not run GC, you have a
potential
memory leak.
On Monday, December 28, 2015 at 5:13:53 PM UTC-5, Mike Jones wrote:
Ref 3.13 of Introduction, ifold2…
Do closures of in general:
Gen code with a malloc call?
Gen code with free after exiting scope?
Meaning, if I am not linking a library with malloc and free I can’t
accidentally use it, and if I do have a library, I can’t accidentally
produce a leak?
For example, the function example sqrmodsum in the text: does it produce
an error when malloc is not available, and if available, does this example
leak? Or does it make one heap object that is reused on each call?
I guess I want to know under what circumstances a nieve maintainer can
get into trouble. My hope is the behavior is either fail to compile, or no
leak. If I am correct, then in which ways can I create a closure that leaks
so I can r cognizant them?
Can you add the cast version in the code or write it here? I think it is important because one might need to pass stack allocated lams to prexisting higher ordered functions. As much as I don’t like casting, for embedded code, this seems the only way, unless there is something not said here.
lam@ I’m not sure what @ means. Does it mean pass tuple, anything, is something non-transparent being made transparent?
Cast does not use {}, why not? Is the compiler figuring it out on its own? If so, should it be {ptr} if explicit?
Cast because by not being ref, it has to be converted to a ptr? Seem messy not to just create a closure as pointer in the first place, so that type checking does its job.
fun{}
sqrmodsum2
(n: int, d: int): int = let
//
var
fopr =
lam@(res: int, x: int): int =
if x mod d = 0 then res + x * x else res
//
in
ifold2(10, $UNSAFE.cast(addr@fopr), 0)
end // end of [sqrmodsum2]
‘lam@’ means to form a closure in a given memory space.
In order words, any closure created with the keyword ‘lam@’ is flat.
I was cutting a bit of corner in my original code. No casting is needed if
ifold2 is replaced with ifold2_:
fun
ifold2_( n: int, f: &(int, int) - int, ini: int) : int =
if n > 0 then f(ifold2_ (n-1, f, ini), n) else ini// end of [ifold2]On Tuesday, December 29, 2015 at 12:31:03 PM UTC-5, Mike Jones wrote:
I need some help with this code:
= I assume overrides a default of
lam@ I’m not sure what @ means. Does it mean pass tuple, anything, is
something non-transparent being made transparent?
Cast does not use {}, why not? Is the compiler figuring it out on its own?
If so, should it be {ptr} if explicit?
Cast because by not being ref, it has to be converted to a ptr? Seem messy
not to just create a closure as pointer in the first place, so that type
checking does its job.
fun{}
sqrmodsum2
(n: int, d: int): int = let
//
var
fopr =
lam@(res: int, x: int): int =
if x mod d = 0 then res + x * x else res
//
in
ifold2(10, $UNSAFE.cast(addr@fopr), 0)
end // end of [sqrmodsum2]
So (…) - means closure on heap which is ptr, and &(…) - means ptr to closure that is not already ptr, on stack or static. Wouldn’t the representation be the same, such that a function taking a closure as argument could take either, assuming something like ptr to tuple with an anonymous function and captured data?
And can you pass a closure by value? That assumes a tuple copy. Not efficient, but curious.
ATS compiler generates the same code. It is just that certain functions
(malloc, free, calloc, and realloc) are
hooked to different implementations (provided by different libraries).On Tue, Dec 29, 2015 at 12:10 PM, Mike Jones proc...@gmail.com wrote:
Since Bohem GC replaces alloc, does the ATS compiler really generate
different code for GC or does it just add some GC initiallization code?
To use malloc, you need to compile with a flag looking like
-DATS_MEMALLOC_???
For instance,
patscc -DATS_MEMALLOC_LIBC -o foo foo.dats // using malloc/free in libc
patscc -DATS_MEMALLOC_GCBDW -o foo foo.dats -lgc // using Bohem GC
If you use malloc but do not use -DATS_MEMALLOC_???, then you will see
the following error message issued by the linker:
undefined reference to `atsruntime_malloc_undef’
If you can compile your ATS code to executable without using
-DATS_MEMALLOC_???,
then your ATS code cannot generate memory leaks (because it does not even
call malloc).On Tue, Dec 29, 2015 at 9:56 AM, Mike jones proc...@gmail.com wrote:
I assume that if there is no alloc/malloc library to link, there cannot be
links, because I kind of remember that for ATS the GC operates via this
API. I would like to confirm that.
The danger for me is my application layers on ThreadX, wrappers by
Cypress, but I think it exposes the alloc/malloc. Would a simple search of
the generated C be enough to determine no leaks? Or are there other calls I
need to check?
To recognize whether the C code generated from ATS source
does something bad (e.g., leaks memory), one needs to analyze the
C code. Tools need to be developed for doing such analysis.
On Monday, December 28, 2015 at 7:28:14 PM UTC-5, gmhwxi wrote:
In general, malloc needs to be called to construct a closure.
However, ‘free’ is not called automatically. If you use a linear
closure (cloptr) but do not call ‘free’, you will get a type-error
somewhere.
If you use a persistent closure (cloref), you can not free the closure
explicitly
(in a type-safe manner). Instead, GC is needed to reclaim the closure.
In other words, if you create a cloref but do not run GC, you have a
potential
memory leak.
On Monday, December 28, 2015 at 5:13:53 PM UTC-5, Mike Jones wrote:
Ref 3.13 of Introduction, ifold2…
Do closures of in general:
Gen code with a malloc call?
Gen code with free after exiting scope?
Meaning, if I am not linking a library with malloc and free I can’t
accidentally use it, and if I do have a library, I can’t accidentally
produce a leak?
For example, the function example sqrmodsum in the text: does it produce
an error when malloc is not available, and if available, does this example
leak? Or does it make one heap object that is reused on each call?
I guess I want to know under what circumstances a nieve maintainer can
get into trouble. My hope is the behavior is either fail to compile, or no
leak. If I am correct, then in which ways can I create a closure that leaks
so I can r cognizant them?
Please Professor, can you add the “documentation” tag to this thread?Le mardi 29 décembre 2015 19:40:05 UTC+1, gmhwxi a écrit :
The annotation ‘’ means that IF the function is passed as an
argument
(to another function), then a closure is formed. If the function is never
passed as
an argument, there is no closure formation.
This code is of ATS1-style. I think ‘’ can be erased here without
causing
any problems.