#655: Kill non-working GC cores
-------------------------+--------------------------------------------------
Reporter: whiteknight | Owner:
Type: RFC | Status: new
Priority: normal | Milestone:
Component: none | Version: 1.1.0
Severity: medium | Keywords:
Lang: | Patch:
Platform: |
-------------------------+--------------------------------------------------
Comment(by whiteknight):
Replying to [comment:3 doughera]:
> Replying to [ticket:655 whiteknight]:
>
> > src/gc/res_lea.c is an attempt to write a GC core transparently behind
custom malloc calls, but it doesn't work. It also no longer respects the
GC API, redefining several functions that will cause compile-time
conflicts if we enable it.
>
> I think this, or something that plays a similar role, should not be
lightly deleted. It "no longer respects the GC AP", but that's only
because the GC API has changed. I think it's useful to maintain this file
(or create a new "trivial" GC core under the new GC API that plays the
same role).
You are right, the GC API has changed significantly recently, and it
wouldn't be impossible to update this file to satisfy the new API. I'll
have to do some more research on this file to see what kinds of effort
would be necessary, and what the current state of the code is. It's not
just the GC that has changed recently, a lot of Parrot has been changing
recently.
> 1. The hand-rolled "Buffer + refcount" structure in resources.c is
clunky to use and difficult to get right. If buffers indeed are supposed
to carry around a refcount member, they should explicitly do so. (See the
pictures in include/parrot/pobj.h.)
>
> 2. The combination of COW and strings is (or was, last I worked on
this) too tangled in with the specific implementation in
src/gc/reources.c. When last I worked on this, I had everything else
working. Only a couple of string tests failed.
That's not a problem that I was aware of. I haven't spent a lot of effort
digging into the way string buffers were allocated and managed. Improving
encapsulation in this area might be a very good project to tackle in the
near future. Maybe create a new ticket to address it?
> Pragmatically, it might indeed be easier to delete all three and then
re-create something vaguely equivalent to res_lea.c as a way of testing
whether the API is indeed sufficient. I have no objections to such a
plan.
I guess what I'm tying to figure out is this: (1) is this file salvageable
enough that with a reasonable effort we could get it "working" and
"passing all tests", (2) Even if it works, does this method provide any
particular benefits that are worth having, besides the novelty of having a
second GC core, and (3) Is there any benefit to a salvage mission over
deleting this file as part of a general cleanup effort so we can take
stock of what we do have and implement what we will eventually want?
Newer "dream" GC cores will be easier to produce if we clear out unused
garbage and have a cleaner work environment with fewer distractions. If
res_lea.c is not part of the way forward, then it is part of the mess
that's obscuring that way.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/655#comment:4>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
