IIRC this has been discussed on IRC quite a while ago. I think the
consensus was that runtime selection of GCs is not very important.
There are also two parts to the issue. The first one is the wrapper
functions in src/gc/api.c. They could be folded into the GC backends
with very small duplication of code. Then the users of the GC API could
immediately make the indirect function call into the GC backend saving a
function call in many hot paths.
The second part is compile-time selection of the GC backend which is a
lot more flexible. For example, new GC backends could use different
memory layouts for GCables or use their own macros for certain operations.
The work on the configure side shouldn't be too hard. I wrote the
configure code for the new src/platform system and it's basically just
selecting a bunch of .o files depending on a configure option. I can
offer to help working on a similar system for the GC code. But it would
be interesting to know if there are any users of the old GC backends at
all. I always found the "infinite" GC useful for debugging, personally.
Nick
On 12/09/11 18:06, Andrew Whitworth wrote:
That would alleviate pain but would certainly be more work right now.
My big concern is testing this to see if there is a performance
improvement to be had. None of the cores we have besides GMS is worth
going through the effort for, and we don't even have plans on the
table yet for an alternate.
In reality, a system like what we have for src/platforms/* would work
very well for GC. We could set some macros at configure time and make
certain files be included in the build and others excluded, then we
could do static symbol binding on all GC symbols. That's a little bit
more effort than I would like to spend on this right now, especially
since I don't know if the performance gains will be worth it.
--Andrew Whitworth
On Mon, Sep 12, 2011 at 11:56 AM, Jonathan "Duke" Leto
<[email protected]> wrote:
Howdy,
A while ago we talked about allowing GC's to be chosen at compile time.
Wouldn't that alleviate this pain whilst still allowing GC's to be
pluggable?
Duke
On Mon, Sep 12, 2011 at 7:59 AM, Nicholas Clark<[email protected]> wrote:
On Mon, Sep 12, 2011 at 10:42:17AM -0400, Andrew Whitworth wrote:
Is anybody out there using or relying on the alternate GCs besides
GMS? I think I want to rip the older ones out. Right now, because GCs
are pluggable, we have to go through an indirect function call for
every single GC API call, and the C optimizer can't really do anything
with that. I want to rip out the alternate GC cores and flatten some
of the call graphs, to give the C compiler some opportunities to
optimize the hot paths. I will put together a branch soon, but I want
to double-check nobody relies on the old GC cores for any purpose.
The idea of pluggable GCs is great in theory, but right now we only
The idea of pluggable GCs is great in theory, but I can't see how it can
be done (in practice, in a statically compiled language such as C) without
needing a function call at every single *possible* GC API call. That is,
a call is needed at any point where the union of the implementations of
supported GCs need it, even if it's a no-op for the currently chosen GC.
(Such as a call needed for actions for a write barrier, which always has
to be made, because a runtime pluggable system can't inline the test for
whether an invariant has become breached, or remove it entirely for a GC
that doesn't need write barriers.)
I think compile time flexibility should possible without runtime pain.
But no flexibility is cheaper to maintain.
Nicholas Clark
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
--
Jonathan "Duke" Leto<[email protected]>
Leto Labs LLC
209.691.DUKE // http://labs.leto.net
NOTE: Personal email is only checked twice a day at 10am/2pm PST,
please call/text for time-sensitive matters.
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
