A Crazy Thought about CallContext Recycling and Caching

[Andrew Whitworth]

This sounds to me strangely reminiscent of a PIC system: We could
build caches into the call sites in the code with checks. If the same
function/method call with the same arity occurs at the same point we
can use the cached CallContext (and possibly a JIT optimized call
path) instead of creating a new one. A PIC callsite could be it's own
PMC type that contains links to previously-used Sub and CallContext
PMCs, negating the need to do any fancy trickery with the GC or
CallContext.destroy().

This could be a big win especially if we could reduce the use of
find_method calls in a tight loop.

Hardest part here would be inserting call caches into the generated PBC.

--Andrew Whitworth



On Mon, Jan 4, 2010 at 4:23 PM, chromatic <chromatic at wgz.org> wrote:
> Most programs spend most of their time in a few function calls, and most of
> those function calls have static per-call arity and types.
>
> Our CallContext system allows for the few cases where dynamism is necessary
> and fails to exploit the relative static nature of most calls in most
> programs.
>
> We know:
>
> 1) the point of a call
> 2) (generally) the arity of the call
>
> Can we create a cache (perhaps a PMC?) that allows us to skip recycling
> CallContext PMCs and their register storage locations into the PMC and fixed
> size pools, using the register size (or the pc of the call) as a key into the
> cache?
>
> We'd have to detect when it's safe to recycle a CallContext, but we *could*
> hijack its destroy(), let the GC capture a few, and then store them in the
> cache by size and avoid subsequent GC runs.
>
> (In a program where 70% of the GCables created are for PCC and where half of
> the program's time goes to GC, a 35% improvement seems likely.)
>
> -- c
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>