#1971 need to control SyncObj memory usage

obsolete: 8.4b1
closed-fixed
5
2003-10-28
2002-07-17
Anonymous
No

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

Discussion

  • diff between tclThread.c from distribution and proposed fix

     
    Attachments
  • Don Porter
    Don Porter
    2002-07-17

    • labels: 105679 --> 49. Threading
     
  • Don Porter
    Don Porter
    2002-07-17

    • assigned_to: hobbs --> andreas_kupries
     
  • 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 ?

     
    • assigned_to: andreas_kupries --> hobbs
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2002-08-08

    • summary: memory leak --> need to control SyncObj memory usage
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2002-08-08

    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.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-07-16

    Logged In: YES
    user_id=72656

    Zoran, can you comment on the effects of this?

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-07-16

    • assigned_to: hobbs --> vasiljevic
     
  • 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.

     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2003-07-18

    Logged In: YES
    user_id=72656

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

     
  • 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.

     
    • status: open --> closed
     
  • Logged In: YES
    user_id=95086

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

     
    • status: closed --> closed-fixed