#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 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).
In any case, there are three lessons from res_lea.c that are worth
carrying forward. (These were all valid as of the last time I worked on
the file; I don't know if recent changes have changed them, but I suspect
not.)
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.
3. The existing res_lea file might be at the wrong level of abstraction,
but I think the idea is sound. If parrot has a GC API, it ought to be
possible to write a very simple GC implementation using that API without
having to touch bits and pieces of other files.
> I propose that all three of these be deleted to clear the way for new
cores, and to require less maintenance going forward. Opinions?
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.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/655#comment:3>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
