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

[Björn-Egil Dahlberg]

Den 16 januari 2012 18:24 skrev Jon Watte <jwatte@REDACTED>:

> 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.
>

Hmm, yes, I did not answer correctly to the example. (Bad teacher) "A"
isn't used in the above example so it will be garbed. Let me show you by
example what I mean.

-module(test).

-compile([export_all]).

go1() ->
    {ok, A} = file:read_file("test.erl"),
    go1(A).

go1(A) ->
    ok = nothing(A),
    erlang:garbage_collect(),
    io:format("~p~n", [erlang:process_info(self(), binary)]),
    ok.

go2() ->
    {ok, A} = file:read_file("test.erl"),
    go2(A).

go2(A) ->
    erlang:garbage_collect(),
    ok = nothing(A),
    io:format("~p~n", [erlang:process_info(self(), binary)]),
    ok.

nothing(_) -> ok.


What will the two functions go1 and go2 produce?

Eshell V5.9.1  (abort with ^G)
1> test:go1().
{binary,[]}
ok
2> test:go2().
{binary,[{11960880,575,2}]}
ok


// Björn-Egil


> 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/efee0a90/attachment.htm>