Cheers Laurent - perfectly acceptable answer from Jeff, and I can see the
logic behind it. Thanks for looking into it for me. Satisfied my curiosity
anyway!
Steve Flynn
NOP Data Migration Ops Analyst
* 01603 687386
-----Original Message-----
From: Laurent Duperval [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, September 06, 2001 5:04 PM
To: [EMAIL PROTECTED]
Subject: Re: [expert] Netscape & wish using up memory
On 6 Sep, To: [EMAIL PROTECTED] wrote:
> On 5 Sep, FLYNN, Steve wrote:
>> Exactly what is the point in that? I've never done any Tcl
programming
>> (yet) but I can't see the reasoning behind this.
>>
>
> I don't remember what the exact design decision was. It may have
been
> somnething to do with performance. I'll ask and give you the
answer later.
>
>> It's a multi-tasking OS - everything should be handed back in a
friendly
>> manner. It sounds like a deliberate design ploy on the Tcl
interpreter
>> authors, presumably for performance increases, but it appears to
fail as
>> it causes swapping itself!
>>
>> Have I got the wrong end of the stick?
>>
>
> In this case, probably. I suspect the the tkppoe script keeps
large
> amounts of data in memory and never releases it. For example,
maybe it
> sets an array aor a list and constantly adds data to it. In that
case, no
> matter what Tcl does with memory, it will just keep on growing and
> growing.
>
> On the other hand, if the script allocates large amounts of data
to do
> temporary datamanipulation, then releases the handle to that data,
the
> memory growth will be a result of the way Tcl manages memory.
Until I see
> the script, I can't say for sure which of these situations is at
work.
>
> L
>
As promised, here is Jeff Hobbs' answer, which you can find on
comp.lang.tcl
(and I think any subsequent discussions on the memory allocation
aspect of
Tcl should be taken there):
Yes, it is in large part for performance. Yes, it still makes a
noticable difference in that latest machines, and likely always will
since the concept is fairly basic. This is exactly what Tcl does:
It allocates Tcl_Obj's in blocks of 100. Ask for the first one, you
get 100 and it pops one off to you. The next 99 are already
allocated
and just popped off to you.
When you "free" a Tcl_Obj, it goes back on to a stack of free
objects
which can be reused. Any memory associated with the Tcl_Obj
(string,
list rep, other object data) is all freed, it is just the Tcl_Obj
shell that is kept on the stack for reuse.
This means if you have 1001 objects in use at once, you will have
allocated at least 1100 Tcl_Obj's. However, if you used 1001
objects,
but never more than 50 at a time, you only ever allocated 100
Tcl_Obj
(others were reused). This goes on for the lifetime of the process.
Thus, the objects used high-water mark is maintained - with the
philosophy that if you used it before, you may need it again.
The way in which they are maintained on the stack is done in a very
efficient manner (linking to each other), which unfortunately makes
it impossible to deallocate. To free, you would have to have the
entire block of 100 Tcl_Obj's ready to free and remember which one
was the first.
What the person may have been seeing is some mem leak in Tcl. There
were (*were*) a few that we hard to exercise, but 8.3.2 had a fairly
easy to hit one in channels (unfortunately) that was fixed in 8.3.3.
So, while it is true that certain parts of Tcl don't free mem back,
it is just the Tcl_Obj shell allocator, everything else gets freed
(structures, dstrings, strings, ...).
-----------
Since tkpppoe most likely uses channels, it may be exercising the
bug that
Jeff mentions. You could try 8.3.3 to see if your script still
ill-behaves.
L
--
Laurent Duperval <mailto:[EMAIL PROTECTED]>
Ne vous moquez pas maître. C'est le titillement de la recherche
scientifique
qui me fit sortir du lit, malgré l'aube matinale de l'après-midi!
-Le disciple
<< File: message.footer >>
**********************************************************************
This email and any files sent with it are intended only for the named
recipient. If you are not the named recipient please telephone/email
the sender immediately. You should not disclose the content or
take/retain/distribute any copies.
**********************************************************************
Norwich Union Life & Pensions Limited
Registered Office 2 Rougier Street
York YO90 1UU
Registered in England Number 3253947
A member of the Norwich Union Marketing Group
which is regulated by the Personal Investment Authority.
Member of the Association of British Insurers.
For further Enquires 01603 622200
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
