I'm trying to understand why the code below generates over 3 MB of
simple-character-string garbage that isn't dealt with by the SBCL x86
GC. I suspect that a poor understanding of the GC is the tip of the
iceberg (hence the post here rather than on a SBCL list)... In
particular,
- what, specifically, is generating the string garbage (or am I
foolish to believe ROOM?)?
- why is the string garbage persisting (or am I twice foolish to
believe ROOM?)?
Thanks in advance for any thoughts/pointers/advice/reading
suggestions/...
- Alan
* (sb-ext:gc :full t) (room)
Dynamic space usage is: 26,093,336 bytes.
...
Garbage collection is currently enabled.
Breakdown for dynamic space:
9,383,560 bytes for 11,371 code objects.
4,795,664 bytes for 599,458 cons objects.
3,278,896 bytes for 75,171 instance objects.
3,012,024 bytes for 53,661 simple-vector objects.
5,635,464 bytes for 134,127 other objects.
26,105,608 bytes for 873,788 dynamic objects (space total.)
*
;; generate lots of errors...
(dotimes (x 10000)
(handler-case (eval '(setq (list 1 2) 1))
(error () :ERROR)))
* (sb-ext:gc :full t) (room)
Dynamic space usage is: 35,791,488 bytes.
...
Garbage collection is currently enabled.
Breakdown for dynamic space:
11,303,560 bytes for 21,371 code objects.
6,029,104 bytes for 753,638 cons objects.
5,800,192 bytes for 142,776 instance objects.
3,687,688 bytes for 85,914 simple-vector objects.
3,349,168 bytes for 25,452 simple-character-string objects.
6,591,848 bytes for 234,181 other objects.
36,761,560 bytes for 1,263,332 dynamic objects (space total.)
*
note(s):
- ECL also exhibits a significant jump in memory use after this; clisp
doesn't
·········@gmail.com wrote:
> I'm trying to understand why the code below generates over 3 MB of
> simple-character-string garbage that isn't dealt with by the SBCL x86
> GC. I suspect that a poor understanding of the GC is the tip of the
> iceberg (hence the post here rather than on a SBCL list)... In
> particular,
> - what, specifically, is generating the string garbage (or am I
> foolish to believe ROOM?)?
> - why is the string garbage persisting (or am I twice foolish to
> believe ROOM?)?
I think "tip of the iceberg" is right. What state are you in after
having generated all these errors? Have they all been handled so that
you're back to the status quo ante? Because string garbage (if garbage
it be) seems the least of your problem from that dynamic space
breakdown. You've got tens of thousands of additional objects of many
different kinds (some overlapping, and I would guess that many of them
are associated with all the things that usually get saved for the user
to look at when an error is signalled.
Or am I crazy?
> Thanks in advance for any thoughts/pointers/advice/reading
> suggestions/...
>
> - Alan
>
>
> * (sb-ext:gc :full t) (room)
>
> Dynamic space usage is: 26,093,336 bytes.
> ...
> Garbage collection is currently enabled.
>
> Breakdown for dynamic space:
> 9,383,560 bytes for 11,371 code objects.
> 4,795,664 bytes for 599,458 cons objects.
> 3,278,896 bytes for 75,171 instance objects.
> 3,012,024 bytes for 53,661 simple-vector objects.
> 5,635,464 bytes for 134,127 other objects.
> 26,105,608 bytes for 873,788 dynamic objects (space total.)
> *
>
> ;; generate lots of errors...
> (dotimes (x 10000)
> (handler-case (eval '(setq (list 1 2) 1))
> (error () :ERROR)))
>
> * (sb-ext:gc :full t) (room)
>
> Dynamic space usage is: 35,791,488 bytes.
> ...
> Garbage collection is currently enabled.
>
> Breakdown for dynamic space:
> 11,303,560 bytes for 21,371 code objects.
> 6,029,104 bytes for 753,638 cons objects.
> 5,800,192 bytes for 142,776 instance objects.
> 3,687,688 bytes for 85,914 simple-vector objects.
> 3,349,168 bytes for 25,452 simple-character-string objects.
> 6,591,848 bytes for 234,181 other objects.
> 36,761,560 bytes for 1,263,332 dynamic objects (space total.)
> *
>
>
> note(s):
>
> - ECL also exhibits a significant jump in memory use after this; clisp
> doesn't
I don't think you're crazy. I'm definitely not in the know when
garbage collection issues and heap exhaustion arrive in town... I
would definitely welcome enlightment.. especially with respect to:
1. why the behavior varies across SBCL versions
2. why the objects associated with the error condition, once it has
been handled, should persist
Perhaps my misperception originates with a vague notion that the gc
'has my back' and will deal with objects left lying around (... or was
that my mom years ago?). Something like (dotimes (x 10000) (list x 2
3)) generates lists but they get nicely cleaned up... Nor do things
like
(dotimes (x 10000)
(handler-case (eval 'a)
(error () nil)))
or
(dotimes (x 10000)
(handler-case (eval '(error 'program-error))
(error () nil)))
exhibit the dynamic space gluttony problem. I'm left wondering what
distinguishes these cases from the dynamic space hog
(dotimes (x 10000)
(handler-case (eval '(setq (list 1 2) 1))
(error () nil)))
On Feb 17, 8:51 am, ··········@gmail.com" <·········@gmail.com> wrote:
> I'm trying to understand why the code below generates over 3 MB of
> simple-character-string garbage that isn't dealt with by the SBCL x86
> GC. [...] ECL also exhibits a significant jump in memory use after this; clisp
> doesn't
Fresh ECL image (OS X, latest Boehm-Weiser garbage collector)
38597 ecl 0.0% 0:00.37 1 14 55 3168K 188K
4972K 25M
After errors
38597 ecl 0.0% 0:00.66 1 14 56 4140K 188K
5952K 25M
I do not see such a big peak. Thas to be some memory allocation for
you are creating different objects (interpreted bytecodes, handler
jump points, conditions, etc) and the garbage collector is not called
every time you need memory. The important thing is that once this is
done, if you repeat the process the memory does not grow much more.
38597 ecl 0.0% 0:01.48 1 14 56 4140K 188K
5952K 25M
Juanjo
t> I'm trying to understand why the code below generates over 3 MB of
t> simple-character-string garbage that isn't dealt with by the SBCL x86
t> GC.
on SBCL 1.0.13 there is no dynamic space swelling:
before test: Dynamic space usage is: 25,997,080 bytes.
after test: Dynamic space usage is: 26,070,264 bytes.
so it might be a bug in SBCL or some random fluctuation, as SBCL's GC
is conservative.
On Feb 18, 4:32 am, "Alex Mizrahi" <········@users.sourceforge.net>
wrote:
> t> I'm trying to understand why the code below generates over 3 MB of
> t> simple-character-string garbage that isn't dealt with by the SBCL x86
> t> GC.
>
> on SBCL 1.0.13 there is no dynamic space swelling:
>
> before test: Dynamic space usage is: 25,997,080 bytes.
> after test: Dynamic space usage is: 26,070,264 bytes.
>
> so it might be a bug in SBCL or some random fluctuation, as SBCL's GC
> is conservative.
Thanks. 1.0.12 and 1.0.15 also don't show dynamic space issues...
Guess it is a SBCL 1.0.23 issue...
thus spoke ·········@gmail.com <·········@gmail.com>:
> I'm trying to understand why the code below generates over 3 MB of
> simple-character-string garbage that isn't dealt with by the SBCL x86
[...]
I can reproduce that too on 1.0.25.12.
Could you send it to sbcl-bugs or the launchpad bug tracker so the
report won't get lost?
On Feb 19, 8:16 pm, Stanis³aw Halik <·······@test123.ltd.pl> wrote:
> thus spoke ·········@gmail.com <·········@gmail.com>:
>
> > I'm trying to understand why the code below generates over 3 MB of
> > simple-character-string garbage that isn't dealt with by the SBCL x86
>
> [...]
>
> I can reproduce that too on 1.0.25.12.
>
> Could you send it to sbcl-bugs or the launchpad bug tracker so the
> report won't get lost?
I sent a report to sbcl-devel.