Re: [Chicken-janitors] #1356: trace buffer unnecessarily holds on to thread objects

[Chicken Trac]

#1356: trace buffer unnecessarily holds on to thread objects
-----------------------------------+--------------------
            Reporter:  kristianlm  |      Owner:
                Type:  defect      |     Status:  new
            Priority:  minor       |  Milestone:  5.0
           Component:  unknown     |    Version:  4.12.0
          Resolution:              |   Keywords:
Estimated difficulty:  medium      |
-----------------------------------+--------------------

Comment (by sjamaan):

 I wasn't aware we were using the thread to construct the call chain, that
 really changes things (I thought it was only shown, but obviously that was
 just a brainfart of mine).

 Using just the thread name like this seems really wrong (unless we can
 enforce the name being unique somehow), because the danger is that you'd
 merge call chains from completely unrelated threads, which could quickly
 get really confusing.

 Here's an idea: Perhaps we could treat the "thread" property in the trace
 buffer as a weak reference: Simply avoid marking the thread in the GC, and
 perform a forwarding pointer chase for the live items in the table at the
 end of a GC.  Any dead items should then be marked with {{{#f}}} or
 something.  The {{{get-call-chain}}} already has some code to deal with
 the possibility that the "thread" object is not a thread (which I don't
 quite understand: why would you include any trace entries for non-threads
 in there?), we could extend or tweak that a little.

 I know hacking the GC even more is not ideal and the code for dealing with
 forwarding pointers is rather bulky, but it would provide a conceptually
 elegant solution to the problem: if a thread has been garbage collected,
 it means no call chain will ever be requested for it anyway (because there
 are no references to it anymore).  We could even compress the call chain
 by removing those entries instead of nuking the thread slot (not sure if
 that's a good idea).

 In any case, the precise layout of the call chain is a (mostly?) internal
 interface (it's undocumented for sure) so I'm not even sure we need to fix
 this for 5.0. I think we should probably postpone it. Do you agree?

--
Ticket URL: <https://bugs.call-cc.org/ticket/1356#comment:9>
CHICKEN Scheme <https://www.call-cc.org/>
CHICKEN Scheme is a compiler for the Scheme programming language.