Proxy performance: JIT-compilation?

[Mark S. Miller]

On Fri, Aug 4, 2017 at 2:52 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
wrote:

>
> On Aug 4, 2017, at 2:22 PM, Mark S. Miller <erights at google.com> wrote:
>
> At https://github.com/tvcutsem/es-lab/issues/21 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.
>
> I don’t think the barriers to such optimization are technical.  It’s more
> a matter of convincing that engine implementors that doing the work
> (probably significant)  to optimizing Proxies in this manner is a sound
> investment and hight priority
>

I agree. So I change the claims to

    * should break essentially no current code,
    * repair the cycle detection transparency violation bug,
    * enable many proxies to be *much* faster with less work by
implementors.

In particular, for many permanently absent traps, the proxy can just pass
these through directly to the target without much analysis.

-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170804/01e23fc8/attachment.html>