Proxy performance: JIT-compilation?

Sam Tobin-Hochstadt samth at
Tue Aug 8 21:36:57 UTC 2017

On Fri, Aug 4, 2017 at 4:52 PM, Allen Wirfs-Brock <allen at> wrote:
> On Aug 4, 2017, at 2:22 PM, Mark S. Miller <erights at> wrote:
> At Tom and I have an idea (that
> we should turn into a proposal) for a subtle change to proxy semantics that
>     * should break essentially no current code,
>     * repair the cycle detection transparency violation bug,
>     * enable many proxies to be *much* faster.
> I actually don’t see why any semantic changes are needed to enable better
> Proxy performance. One abstractions are sufficiently lowered, a proxy trap
> invocation is just a series  of procedure calls (some dynamically
> dispatched; some to built-in procedures).  I don’t see any reason why the
> same sort of PIC+dynamic typed based specialization+inlining that is used to
> optimize more conventional JS code isn’t also applicable to Proxy using
> code.

Indeed, this works well in practice with other proxy constructs in
other languages -- my collaborators and I have a paper showing this
that should be out soon. The only barrier to good proxy performance is
implementation work.


More information about the es-discuss mailing list