Re: Garbage collector - ccl:terminate (memory stuff)

Hello Peter,

Le dim. 28 avr. 2024 =C3=A0 11:04, peter <[email protected]> a =C3=A9crit :
>
> Hi Greg,
>
> I'm struggling to get my head around quite what you are trying to do.
> But something that came to mind was from lisp machine lisp (Zetalisp, Gen=
era, etc).
> There we could partition and allocate an area of memory, so we could use =
this area for our code, then GC it entirely in an instant. I have no idea w=
hether such an approach is viable in CCL or SBCL, or whether that would be =
of use for you.
>
> My guess is that you are monitoring your RAM usage while your system is r=
unning, and seeing memory fill up. Effectively suffering a "memory leak".

No, I have just added in the C wrapper to Julia a printf help::
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
void jl_delete_wrapped_index(const char *index)
{
    jl_value_t *res;
    char* nstr =3D "";

    if (!strcmp(nstr, index)){
        jl_printf(jl_stderr_stream(), "ERROR: delete(index): empty index\n"=
);
        return;
    }
    //printf("Freeing... %s\n", index);
    res =3D jl_call2(del, refs, jl_cstr_to_string(index));
    //printf("%s freed\n", index);
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

At the CL level, the jlref class only holds the Julia specialized data
type as a string, and an index that refers to an element in a Julia
hash table. For Float64 or ComplexF64 (double-float-s) that is not a
problem I can call BLAS/LAPACK subroutines "directly" or special
functions applied on scalars so I do not need this hashtable but for
more elaborated data types I use the scheme used in the Julia
documentation (https://docs.julialang.org/en/v1/manual/embedding/),
that is, store the variable in an indexed hashtable.


>
> My thinking in general runs to just ensuring that there are no references=
 left. I once was building a huge evolving tree structure and found myself =
throttled by lack of memory. Eventually I found just one entity in the whol=
e still being referenced. Unfortunately that item also was circuitously con=
nected to a great proportion of the remaining redundant material. My fault =
for keeping redundant pointers.

Yes, clearly. I have some bad memories with trees ;)

But, in fact I will have to later do some checks at the Julia level
for forgotten variables. For now, sometimes, I just print the hash
table after freeing all referenced FriCAS variables.

In  mycase, I only need to store an index '(random
most-positive-fixnum)', so in fact I am playing if I can say that,
with two GCs. And when Clozure CL via FriCAS performs its job, what
I'm trying to do is delete the Julia hashtable entry to let the Julia
GC do its job.

>
> I expect the above may be not much use to you, but it is interesting tryi=
ng to tune in to your issues.

Thanks for your response, my problem was probably not very well
worded. I am still struggling with this but I take a pause with this.
The only thing I have found interesting as of now seems to be the
mac-ui/ and objc-bridge/ code in the Clozure CL source tree. It has an
allusion to keep a ccl:terminate method after a save-application,
which is my case. I will look at this more deeply.