>> How come there are 2 references on it and what to do to free this >> binary? > it is not gc:ed yet.
To be a little more specific. The references (Procbins) to your offheap binary are still on the process heap even though nothing in the rootset is referencing the procbins. A gc will be triggered when the current heap is full, binary vheap is "full" or an explicit garbage_collect is called for, which ever comes first. At that moment the procbins will be removed and the offheap binary will be deallocated (if nothing else is referencing it).
Hibernate is a lot more aggressive, see doc for details, then a gc but is also useful in scenarios when you want to shrink idle workers to a minimum.
Of course, you normally don't need to trigger gc:s or a hibernate unless your application scenario really requires it. Large lingering binaries are a bit of a problem if the space is tight. In those cases an well placed explicit gc is well worth the trade off.
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? _______________________________________________ erlang-questions mailing list erlang-questi...@erlang.org http://erlang.org/mailman/listinfo/erlang-questions
Den 13 januari 2012 23:11 skrev Max Lapshin <max.laps...@gmail.com>:
> 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.
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.
> Den 13 januari 2012 23:11 skrev Max Lapshin <max.laps...@gmail.com>:
> 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.
Den 16 januari 2012 18:24 skrev Jon Watte <jwa...@gmail.com>:
> 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.
> -- > 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.
>> Den 13 januari 2012 23:11 skrev Max Lapshin <max.laps...@gmail.com>:
>> 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.
Again, the question is whether a smart enough compiler or VM couldn't just get rid of this reference? Specifically, because nothing is called without the module specifier, the VM could inline it, and in turn drop the reference to the binary, right? Whereas if the call to nothing was made with module name qualification, then that inline replacement could not take place, and the reference would have to be retained?
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.
> Den 16 januari 2012 18:24 skrev Jon Watte <jwa...@gmail.com>:
> 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.
> 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.
>>> Den 13 januari 2012 23:11 skrev Max Lapshin <max.laps...@gmail.com>:
>>> 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.
