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 <[email protected]> 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 > _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
