Re: Chicken git egg: bug & patch

[megane]

Kristian Lein-Mathisen <kristianlein@gmail.com> writes:

> Hi,
>
> Indeed. We could malloc and set-finalizer! and that should work and be
> safe. However, as far as I understand, this approach has some disadvantages:
>
> - malloc is relatively slow compared to chicken's internal allocation (eg
> make-string) that uses the stack
> - there is a practical limit on finalizers that Chicken can handle
> - large number of set-finalizer!s will slow things down
>
> I forgot to mention that I don't want to go for this approach in this case
> because it will impact us heavily, since we allocate oid objects a lot. I
> believe that is why Evan went for the alternative make-primitive method. So
> I think we really _want_ to involve the Chicken GC, but we need to give it
> some more info than just a #<c-pointer>.
>
> I've used this make-blob approach that is in the attached patches before,
> with success. Unfortunately, it doesn't integrate well with the foreigners
> egg, but I hope it is still a good candidate here for the oid, buf and
> revspec structures.
>

Hi,

Yes, that's all true.

I've only used the finalizer approach with 1000s of finalizers per
second. At this scale the impact is negligible.

If you're generating millions of tiny objects you could also consider
using off heap object pools. If your objects live long enough to get
into the CHICKEN heap they will have a GC impact.

Also worth repeating: passing pointers to CHICKEN objects handled by the
GC to foreign code is unsafe if said pointers are stored and accessed
after the foreign code returns. GC may move the objects and make the
pointers invalid. It's OK if you know the foreign library you're binding
doesn't do this, which I assume is the case here.