Hi!
I originally posted this to sbcl-help, but it occured to me that it's
not all that SBCL specific.
I'm trying to track down references to some objects that are not
getting
garbage collected (see print-out below).
I just can't figure out what is holding on to them, and using
sb-vm::list/map-referencing-objects always indicates that they are not
referenced, although (gc :full t) does not collect them. I read in
another
message that these functions are not very reliable.
What strategy can I now use to find out from where they are referenced?
Btw, I modified the SBCL source to get 1.5 GB dynamic space on x86 32
bit, could this cause
a problem with garbage collection? I would think not, but I'm not
sufficiently
familiar with the insides of SBCL to tell.
I'm using SBCL CVS on Linux 2.6.x and x86 (32 bit).
Thanks,
Chris
* (gc :full t)
NIL
* (sb-vm::type-breakdown :dynamic)
((458666696 2319628 SB-VM::SIMPLE-CHARACTER-STRING)
(98042144 36 SB-VM::SIMPLE-ARRAY-SIGNED-BYTE-30)
(50666136 12727 SB-VM::SIMPLE-ARRAY-UNSIGNED-BYTE-32)
(36464216 55911 SIMPLE-VECTOR) (11661296 11960 SB-VM::CODE)
(5140560 2332 SB-VM::SIMPLE-ARRAY-UNSIGNED-BYTE-8) (4605592 575699
CONS)
(4028352 95944 SB-KERNEL:INSTANCE) (1262432 39451 SYMBOL)
(1051600 31426 SIMPLE-BASE-STRING) (522936 24463 SB-VM::CLOSURE)
(383440 18770 BIGNUM) (297880 1050
SB-VM::SIMPLE-ARRAY-UNSIGNED-BYTE-16)
(254544 15909 SB-KERNEL:FDEFN) (96696 2
SB-VM::SIMPLE-ARRAY-UNSIGNED-BYTE-29)
(56184 2 SB-VM::SIMPLE-ARRAY-UNSIGNED-BYTE-7) (22704 1421
SIMPLE-BIT-VECTOR)
(8112 1014 SB-VM::VALUE-CELL) (4512 564 SINGLE-FLOAT)
(3136 98 SB-VM::ARRAY-HEADER) (1808 113 DOUBLE-FLOAT) (616 77
SB-VM::SAP)
(512 32 RATIO) (128 8 WEAK-POINTER) (80 5 COMPLEX)
(24 1 SB-VM::COMPLEX-DOUBLE-FLOAT) (16 1 SB-VM::COMPLEX-SINGLE-FLOAT)
(16 2 SB-VM::SIMPLE-ARRAY-NIL) (8 1
SB-VM::SIMPLE-ARRAY-UNSIGNED-BYTE-2)
(8 1 SB-VM::SIMPLE-ARRAY-UNSIGNED-BYTE-4)
(8 1 SB-VM::SIMPLE-ARRAY-UNSIGNED-BYTE-15)
(8 1 SB-VM::SIMPLE-ARRAY-UNSIGNED-BYTE-31)
(8 1 SB-VM::SIMPLE-ARRAY-SIGNED-BYTE-8)
(8 1 SB-VM::SIMPLE-ARRAY-SIGNED-BYTE-16)
(8 1 SB-VM::SIMPLE-ARRAY-SIGNED-BYTE-32)
(8 1 SB-VM::SIMPLE-ARRAY-SINGLE-FLOAT) (8 1
SB-VM::SIMPLE-ARRAY-DOUBLE-FLOAT)
(8 1 SB-VM::SIMPLE-ARRAY-COMPLEX-SINGLE-FLOAT)
(8 1 SB-VM::SIMPLE-ARRAY-COMPLEX-DOUBLE-FLOAT))
················@Web.de writes:
> Hi!
>
> I originally posted this to sbcl-help, but it occured to me that it's
> not all that SBCL specific.
>
> I'm trying to track down references to some objects that are not
> getting
> garbage collected (see print-out below).
>
> I just can't figure out what is holding on to them, and using
> sb-vm::list/map-referencing-objects always indicates that they are not
> referenced, although (gc :full t) does not collect them. I read in
> another
> message that these functions are not very reliable.
>
> What strategy can I now use to find out from where they are referenced?
Walk the heap and see in which object there are pointers to these
uncollectable objects. I hear on ix86, sbcl GC is conservative. That
means that there may be at some places bit patterns looking like
pointers to these objects that are not really pointers, just random
data, but just to be sure, sbcl don't collect them.
> Btw, I modified the SBCL source to get 1.5 GB dynamic space on x86
> 32 bit, could this cause a problem with garbage collection? I would
> think not, but I'm not sufficiently familiar with the insides of
> SBCL to tell.
Nice patch!
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You can tell the Lisp programmers. They have pockets full of punch
cards with close parentheses on them." --> http://tinyurl.com/8ubpf
················@Web.de <················@Web.de> wrote:
> Hi!
>
> I originally posted this to sbcl-help, but it occured to me that it's
> not all that SBCL specific.
>
> I'm trying to track down references to some objects that are not
> getting garbage collected (see print-out below).
>
> I just can't figure out what is holding on to them, and using
> sb-vm::list/map-referencing-objects always indicates that they are not
> referenced, although (gc :full t) does not collect them. I read in
> another message that these functions are not very reliable.
>
> What strategy can I now use to find out from where they are referenced?
There are several reasons why LIST-REFERENCING-OBJECTS isn't fully (or
even moderately) accurate. Maybe one of these will ring a bell in the
context of your application:
1. As noted, the GC is partly conservative on x86 (for values on the
C stack or in registers which look like pointers to the dynamic
space), which LIST-REFERENCING-OBJECTS doesn't take into account.
As a quick test for whether the objects are being retained due to
conservativeness, save a core with SAVE-LISP-AND-DIE and load it
back.
2. The heuristic that's used for detecting "old" references to the
object from ones that were generated during the execution of
LIST-REFERENCING-OBJECTS doesn't work correctly on x86. If you
have access to e.g. a ppc machine, you could also test there.
3. Some objects are ignored/not handled in the code that grovels for
references. One such thing, which could cause problems, are lexical
variables that have been closed over.
4. Any special variable bindings that have been shadowed by rebinding
the special will be ignored.
5. On threaded builds, the thread-local storage of threads other
than the one running LIST-REFERENCING-OBJECTS will be ignored.
For 2 and 3, you could try the following patch:
<http://jsnell.iki.fi/tmp/lro.diff>
--
Juho Snellman
················@Web.de writes:
> Btw, I modified the SBCL source to get 1.5 GB dynamic space on x86
> 32 bit, could this cause a problem with garbage collection? I would
> think not, but I'm not sufficiently familiar with the insides of
> SBCL to tell.
You could be increasing the possibility that the conservative garbage
collector mistakes data for pointers by making the dynamic space
larger.
--
Fred Gilham ······@csl.sri.com
All languages have Lisp syntax, of course, except that so many of them
insist on encrypting it using a mechanism called "grammar."
-- Drew McDermott