[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] libpoke: Use uncollectable memory instead of GC roots
From: |
Jose E. Marchesi |
Subject: |
Re: [PATCH] libpoke: Use uncollectable memory instead of GC roots |
Date: |
Thu, 22 Apr 2021 10:40:51 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Hi Mohammad!
> The comments from `gc/gc.h`:
>
> /* new object is cleared. GC_malloc_uncollectable allocates */
> /* an object that is scanned for pointers to collectible */
> /* objects, but is not itself collectible. The object is scanned even */
> /* if it does not appear to be reachable. GC_malloc_uncollectable and */
> /* GC_free called on the resulting object implicitly update */
> /* GC_non_gc_bytes appropriately. */
>
>
> And also this paragraph from https://www.hboehm.info/gc/gcinterface.html:
>
> Identical to GC_MALLOC, except that the resulting object is not
> automatically deallocated. Unlike the system-provided malloc, the
> collector does scan the object for pointers to garbage-collectable
> memory, even if the block itself does not appear to be reachable.
> (Objects allocated in this way are effectively treated as roots by
> the collector.)
I like this solution. We are effectively using the reference-counting
schema of the AST to allocate/free these fields, like the rest of the
node contents. Very good.
I wasn't aware of the fact that GC_malloc_uncollectable effectively
adds a GC root... hopefully there is not a limit of objects allocated
this way? Because in that case we would be in exactly the same problem
than before :)
If there isn't any limit, then this is OK for both master and
maint/poke-1.
I assume this fix is fixing the hard-limit you was finding while loading
pickles?
> Georgiy Tugai (SAL9000) was correct!
Yes :)
Maybe the GC can now be activated in Windows without catastrophic
crashes...