Lisp HUG Maillist Archive

memory usage in capi

I find when using LW4.2.7 on Windows that if I generate many interfaces,
each uses some of my RAM which is not released when the interface is closed,
even though I haven't maintained (I think) any references to the interface
object. I would think it would be garbage collected. Does anyone have any
insight into what I may be doing wrong? Is it possible that CAPI maintains
references to closed interfaces?

Thanks,

Jim Bushnell


Re: memory usage in capi

jcbushnell2@comcast.net writes:

> I find when using LW4.2.7 on Windows that if I generate many interfaces,
> each uses some of my RAM which is not released when the interface is closed,
> even though I haven't maintained (I think) any references to the interface
> object. I would think it would be garbage collected. Does anyone have any
> insight into what I may be doing wrong? Is it possible that CAPI maintains
> references to closed interfaces?

Did you try to run (mark-and-sweep 2) to see if the memory gets released
then? (If it didn't, you sometimes also need to collect generation 3
with (mark-and-sweep 3), though if data gets promoted to generation 3 you
might have hit a gc bug)

(You should also read the "Storage management" chapter of the User Guide)
-- 
  (espen)


Re: memory usage in capi

Unable to parse email body. Email id is 813

Re: memory usage in capi

----- Original Message -----
From: <davef@xanalys.com>
To: <jcbushnell2@comcast.net>
Cc: <lisp-hug@xanalys.com>
Sent: Wednesday, January 29, 2003 5:28 AM
Subject: Re: memory usage in capi


>
>    I find when using LW4.2.7 on Windows that if I generate many
interfaces,
>    each uses some of my RAM which is not released when the interface is
closed,
>    even though I haven't maintained (I think) any references to the
interface
>    object. I would think it would be garbage collected. Does anyone have
any
>    insight into what I may be doing wrong? Is it possible that CAPI
maintains
>    references to closed interfaces?
>
> One thing to check is that you are not simply holding on to the
> interface in the value of *, **, or ***.
>
> What evidence do you have that the uncollected memory is CAPI
> interface objects?
>
> How are you closing the interfaces?
>
>
> Dave Fox
> Xanalys
> Compass House
> Vision Park
> Chivers Way
> Histon
> Cambridge
> CB4 9AD
> England
>
> Email: davef@xanalys.com
> Tel:   +44 1223 253793
> Fax:   +44 1223 257812
> These opinions are not necessarily those of Xanalys.
>
The percentages given are all obtained by Control Panel -> System ->
Performance in Windows on a computer using ME with 384 MB memory.

Start up LWW 4.2.7 and load interface definition files
Now 80% free

Make 25 instances of the interface by:
(dotimes (i 25) (make-instance 'complicated-interface))

Still 80% free

Make and display 25 instances of the interface by:
(dotimes (i 25) (capi:display (make-instance 'complicated-interface)))

Now 53 % free (all the interfaces are now displayed)

Close each interface by clicking in the upper right-hand corner

Now 65% free

The puzzle to me is why the 53% only goes up to 65%, rather than the 80%
free as in making instances without displaying them.

(mark-and-sweep 2) or (mark-and-sweep 3), as suggested by Espen Vestre,
appears to release no memory, as indicated by Control Panel.

Thanks,

Jim Bushnell


Re: memory usage in capi

* jcbushnell2  wrote:
> (mark-and-sweep 2) or (mark-and-sweep 3), as suggested by Espen Vestre,
> appears to release no memory, as indicated by Control Panel.

I notice you are measuring the memory used with Control Panel. Does LW
hand back memory to the OS on a MARK-AND-SWEEP?  I don't know, but
it's quite plausible that it does not do so, so the control panel will
see the memory only increase or stay constant.  This would be quite
normal for many applications - once they've grabbed some memory from
the OS they don't hand it back, but hang on to it in case they need it
again.

For LW on Linux, MARK-AND-SWEEP does not seem to hand memory back to
the OS, but CLEAN-DOWN does - given the following:

(defun allocate-bigly (n)
  (loop repeat n
        collect (make-array 10000))
  (* n 10000))

then calling (allocate-bigly 1000) will cause memory usage to go up to
~75MB.  MARK-AND-SWEEP won't change this, but CLEAN-DOWN will reduce
it to ~29MB again.

Iterating these two operations a few times seems not to cause any
significant memory to leak from the OS's point of view.

Note that a large memory footprint in the sense of a large chunk of
memory allocated from the OS is not really a bad or expensive thing -
virtual memory should be pretty much free.  What counts is how much
much of it is actually being touched from moment to moment.

--tim


Updated at: 2020-12-10 09:01 UTC