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

Apologies for only half understanding this conversation. Are you trying to m=
ake sure C data structures are reclaimed in a hybrid C/Lisp application?

--Tim

> On May 1, 2024, at 08:16, Gr=C3=A9gory Vanuxem <[email protected]> wrote=
:
>=20
> =EF=BB=BFHello Peter,
>=20
>> Le dim. 28 avr. 2024 =C3=A0 11:04, peter <[email protected]> a =C3=A9crit=
 :
>>=20
>> Hi Greg,
>>=20
>> 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 t=
his area for our code, then GC it entirely in an instant. I have no idea whe=
ther such an approach is viable in CCL or SBCL, or whether that would be of u=
se for you.
>>=20
>> 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".
>=20
> 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 "";
>=20
>    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
>=20
> 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.
>=20
>=20
>>=20
>> 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 t=
hrottled by lack of memory. Eventually I found just one entity in the whole s=
till being referenced. Unfortunately that item also was circuitously connect=
ed to a great proportion of the remaining redundant material. My fault for k=
eeping redundant pointers.
>=20
> Yes, clearly. I have some bad memories with trees ;)
>=20
> 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.
>=20
> 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.
>=20
>>=20
>> I expect the above may be not much use to you, but it is interesting tryi=
ng to tune in to your issues.
>=20
> 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.
>=20