[erlang-questions] gen_server state is not released for gc

[Jon Watte]

Is this an artifact of the current implementation?
Semantically, I don't see why a sufficiently smart VM wouldn't be able to
collect the binary at that point.

Sincerely,

jw


--
Americans might object: there is no way we would sacrifice our living
standards for the benefit of people in the rest of the world. Nevertheless,
whether we get there willingly or not, we shall soon have lower consumption
rates, because our present rates are unsustainable.



2012/1/13 Björn-Egil Dahlberg <wallentin.dahlberg@REDACTED>

> Den 13 januari 2012 23:11 skrev Max Lapshin <max.lapshin@REDACTED>:
>
> I thought, that calling gc will be a problem:
>>
>>
>> A = crypto:rand_bytes(1024*1024*1024),
>> erlang:garbagecollect(),
>> {reply, ok, State}
>>
>>
>> Will gc free A? I think that no, because A is still used in the place,
>> where gc is called. Am I right?
>>
>
> Correct.
>
> To be a little technical (and don't take this as an absolute truth in the
> details),
> What we see here is "A is referencing a large binary", which is true. What
> happens internally is that Eterm A is a boxed pointer from the stack or a
> register which points to a ProcBin on the heap. The ProcBin in turn holds
> an increment of a Reference counted binary off heap. Both the stack and the
> registers will become part of the root set during the garbage collection
> hence letting the binary be reachable and therefore "live".  I believe that
> you need leave the function (release the stack) in order to free your
> binary.
>
> A gc without the A in the stack will not let the ProcBin survive during
> the copy phase of the gc. When the ProcBin is removed the RefcBinary will
> decrement and if it reaches zero, i.e. the last ProcBin has died, that too
> will be removed.
>
> // Björn-Egil
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120116/43219175/attachment.htm>