[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-janitors] #1356: trace buffer unnecessarily holds on to thr
From: |
Chicken Trac |
Subject: |
Re: [Chicken-janitors] #1356: trace buffer unnecessarily holds on to thread objects |
Date: |
Fri, 27 Oct 2017 19:11:15 -0000 |
#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.