#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 [comment:4 whiteknight]:
> 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",
It's hard to say. I think with less than an hour's work, I could have
parrot-1.1.0 passing everything but a few string tests. (Most of that
time would be figuring out how to work the headerizer and tweaking
Configure.pl to get the Makefile right.) That's where I got stuck before.
Some more background, and some speculations about what might be going
wrong, is in RT, in [perl #42774]. My memory on what was going wrong is
fuzzy (and my note at the top of res_lea.c is nearly two years old, which
probably explains why).
I have no estimate for how much work would be involved in bringing it in
sync with the current GC API, because I have no idea what has changed. I
can say that the res_lea.c file is deliberately intended to be extremely
simple, so it's probably not too hard to adapt. I suspect we'd still end
up with the same few string failures.
That said, since res_lea.c is deliberately kept simple, it's also probably
not going to be that big of a deal to re-create a similar file from
scratch to work with the new GC API.
> (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.
I think it's a bit of both. Every place where it's obscuring the way
(outside of Configure and res_lea.c itself) is a place where it's pointing
out that perhaps the current resources.c implementation is leaking
internal details. (And the fact that it currently fails some strings
tests signals that we're missing a few more spots.)
On balance, I think the problems are probably at a higher level of
abstraction and encapsulation,
so whatever plan makes it easiest for you to address such higher level
issues is probably the best. I suspect that means deleting all the cruft.
Just be sure to question why each #ifdef was required before deleting it.
As long as it's possible to come back later and reimplement a "clean-
room" GC based on the new API, it should be ok.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/655#comment:5>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
