You can find the places where garbage is collected using ProfileView; bars in
red correspond to lines that trigger gc. For this to work properly, your C
backtraces have to resolve the function name correctly. That worked for me on
Kubuntu 12.04, but after upgrading to Kubuntu 14.04 now I get garbage back
from C backtraces. (Go figure.) In that case, I recommend saying
ProfileView.view(C=true)
and then at least you can guess that it's a gc event from the tall stack of
bars (the garbage-collector is heavily recursive).
Of course, garbage collection does not always happen at every line that
triggers allocation. You may also be interested in
https://github.com/JuliaLang/julia/pull/7464
which more directly detects allocation. It should work on your machine as long
as you don't "make install" julia in a separate directory from where you
cloned it (that proves to be the source of the Travis failure).
--Tim
On Tuesday, July 08, 2014 11:22:46 AM Douglas Bates wrote:
> I believe I saw discussion of finding areas of memory allocation in the
> output of Profile.view() or the flame plot from ProfileView.view().
> However, like so many other things, I fail to remember the details.
>
> The particular case I am interested in is described in an IJulia notebook
> called Bootstrap.ipynb in the repository github.com/dmbates/JuliaWorkshop.
> I have eliminated almost all of the memory allocation in the inner loop of
> a simulation but there is some vestigial allocation going on that I can't
> track down.
>
> The notebook can be viewed at
>
> http://nbviewer.ipython.org/github/dmbates/JuliaWorkshop/blob/master/Bootstr
> ap.ipynb
