Tcl Source Code

View Ticket
Login
Ticket UUID: 582810
Title: need to control SyncObj memory usage
Type: Bug Version: obsolete: 8.4b1
Submitter: nobody Created on: 2002-07-17 13:00:08
Subsystem: 49. Threading Assigned To: vasiljevic
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2003-10-28 20:23:26
Resolution: Fixed Closed By: vasiljevic
    Closed on: 2003-10-16 09:26:35
Description:
SyncObjRecord in tclThread.c has unlimited growth--it's 
realloced when full always with extra 8 slots, e.g. it 
should add these slots only when there is less than 8 
slots filled
User Comments: vasiljevic added on 2003-10-16 16:26:35:
Logged In: YES 
user_id=95086

I'm closing this one since it is now merged in head.

vasiljevic added on 2003-07-20 01:20:24:
Logged In: YES 
user_id=95086

Works fine. 
During some simple quick tests without patch, the table grew 
to 256 entries. With patch, it was steady at 40/48 entries. 
I'd only consider using register for loop counters in such 
tight loops. Otherwise, I have no complaints. 
You can put it in 8.4.4, IMHO.

hobbs added on 2003-07-19 00:28:51:
Logged In: YES 
user_id=72656

Can you test the patch attached in one of your more 
intensive threaded tests?

vasiljevic added on 2003-07-18 18:41:25:
Logged In: YES 
user_id=95086

I agree with your oppinion. I also think that Andreas suggestion 
would be ok. Instead of always allocating new, we might just 
remember (in the LIFO free list) void slots and reuse them again.

hobbs added on 2003-07-17 06:26:44:
Logged In: YES 
user_id=72656

Zoran, can you comment on the effects of this?

hobbs added on 2002-08-08 13:57:46:
Logged In: YES 
user_id=72656

tclThread.c:RememberSyncObject
The problem seems more fundamental, in that recPtr->num 
only ever increases (except at finalization, when set to zero 
again).  The memory is released, but we aren't using it well, 
because if SyncObjects are forgotten, num isn't 
decremented, and there is no reuse of pointers in the list.

andreas_kupries added on 2002-08-07 05:32:03:
Logged In: YES 
user_id=75003

Question is how much memory do we lose here
because of this.

And, how much time do we lose by searching through
the array for free entries ? Do we have info on the size of
arrays during execution ?

Alternative implementation: a free-list using one additional 
element in the structure, to anchor the list, and the 
references to the next free entry are kept in the free entries
(integer's, not as pointers, relocatable).

Your opinion Jeff ?

nobody added on 2002-07-17 20:00:09:

File Added - 27229: tcl.bug

Attachments: