delete is destroy + GC.free()

[p0nce]

<adam_d_ruppe> destroy sets it to null, but doesn't actually free the memory - it leaves the GC to determine if there are other references
<adam_d_ruppe> with a large array, the accidental pin effect means the GC might THINK there's another ref when it is just a false pointer
<p0nce> my understanding was that delete also let the GC decide
<adam_d_ruppe> rare on 64 bit, but common on 32 bit
<p0nce> oh my, delete can override a false pointer?
<adam_d_ruppe> delete in fact does call GC.free, leaving references dangling if there are any (and that's why they want it out of the language - memory unsafe if it is a true pointer)
<adam_d_ruppe> yeah
<p0nce> that can be useful
<p0nce> delete is destroy + GC.free()?
<adam_d_ruppe> you can replace it with .destroy/GC.free lib calls too. well, until the deprecate GC.free too
<adam_d_ruppe> yeah
<p0nce> ok. everything make sense again

[p0nce]

Title would be something like "Forcing the GC to be less conservative", "Wrestling with false pointers", "Conservative GCs hate this trick!"

[p0nce]

More ketmar tricks:

<ketmar> but if you'll slice such array, slice won't anchor it too. so if there is no pointer to array's head... BOOM! segfault or memory corruption
<ketmar> it is not about scanning a block. it is about deciding if the found pointer points to that block or not
<ketmar> if you have 50MB block, any pointer inside those 50MB will prevent collecting. with NO_INTERIOR, only pointer to the first byte of the block will
<ketmar> i mean, anything outside the block that *looks* like a pointer to it
<ketmar> that is, suddenly, you have to do precision shots with pointers, and that decreases falst positives to almost zero
<ketmar> but then you have to manage lifetime of array slices manually
<p0nce> thanks for the explanation. That sounds similar to a malloc area? you can slice it if you manage the lifetimes properly
<ketmar> yeah. almost the same, but without manual `free()` -- GC is still responsible for alloced mem. only it can collect it sooner than you expecting ;-)

[p0nce]

NO_INTERIOR is used as an intermediate between regular GC code and "manual memory management", still leaving free() to the GC if you manage lifetimes correctly.

[p0nce]

Not an issue anymore with recent GC