Ticket #379 (closed defect: fixed)

Opened 2 months ago

Last modified 2 months ago

results of HEAP-UTILIZATION on x8632 are fishy

Reported by: rme Assigned to: gb
Priority: minor Milestone: IA-32 port
Component: Runtime (threads, GC) Version: trunk
Keywords: Cc:

Description 

Welcome to Clozure Common Lisp Version 1.3-dev-r11353M-trunk  (DarwinX8632)!
? (heap-utilization)
Object type                               Count   Total Size in Bytes
CONS                                      126038          1008304
BOGUS                                          3                0
BIGNUM                                       149             1156
SHORT-FLOAT                                   24               96
DOUBLE-FLOAT                                  12              144
COMPLEX                                        1                8
MACPTR                                       139             2636
FUNCTION                                   12138          5348712
BASIC-STREAM                                  34         22355952
SYMBOL                                     34835           975380
XCODE-VECTOR                                   1                0
LOCK                                         120             2880
HASH-TABLE-VECTOR                             72           324848
POOL                                          23               92
POPULATION                                    22              268
PACKAGE                                       15              480
SLOT-VECTOR                                 4628           199512
STANDARD-INSTANCE                           4183            50196
STRUCTURE                                   3283           123116
INTERNAL-STRUCTURE                          2587            67232
VALUE-CELL                                    19               76
SIMPLE-VECTOR                              23960          1089208
SIMPLE-UNSIGNED-LONG-VECTOR                    1             4092
SIMPLE-BASE-STRING                          7683           473928
SIMPLE-BIT-VECTOR                              1          2097152

Those BASIC-STREAM objects are pretty heavyweight...not to mention the presence of BOGUS and XCODE-VECTOR objects that take up no space.

Change History

11/11/08 17:39:33 changed by gb

Perhaps some of the BOGUS objects are of negative size and others have positive sizes. These things even out ...

I got an x8632 FreeBSD mostly working the other day. The cross-compiled version would fault in CLEAR-IOBLOCK-STREAMS, which walks the heap just before an image is saved. I commented that out and built it natively and eventually reenabled the call to CLEAR-IOBLOCK-STREAMS, but it may be that there are still some problems in %WALK-DYNAMIC-AREA. (I was willing to blame that on cross-compilation artifacts, but it's not clear what those unspecified artifacts would be.)

11/15/08 06:08:21 changed by gb

Trying to save an image on win32: 

? (save-application "new.image")
> Error: Fault during read of memory address #x97
> While executing: CCL::STD-INSTANCE-CLASS-CELL-TYPEP, in process Initial(0).
> Type :POP to abort, :R for a list of available restarts.
> Type :? for other options.
1 >

This is almost certainly the heap walk in CLEAR-IOBLOCK-STREAMS. (It's likely easier to debug the HEAP-UTILIZATION case by setting a breakpoint when we increment an impossible/bogus type's count/size, or when we find one of these gigantic BASIC-STREAMs.)

11/15/08 07:53:37 changed by gb

  • status changed from new to assigned.

This might be fixed by r11363 (at the very least, HEAP-UTILIZATION results look less fishy.)

One way to debug this: - define a stack frame slot "prev" in each of WALK-STATIC-AREA and %WALK-DYNAMIC-AREA. - in each function, store "obj" in "prev" after doing the call (and before incrementing "obj". - set a breakpoint on some anomalous condition in the function (e.g., a BASIC-STREAM with more than 10 elements). When the breakpoint (ccl::dbg) is reached, step through the code on return, look at "prev", maybe set "obj" to "prev" and step through the code that tries to skip past it to the next object.

The "prev" register variable in the PPC and x8664 versions of these functions exists solely for this reason.

11/15/08 07:57:37 changed by gb

  • status changed from assigned to closed.
  • resolution set to fixed.

The win32 lisp that couldn't save an image reliably was able to do so after r11363, so it looks like this is fixed. Knock wood.