Forwarding my examples to the list as suggested by nicholas. Here are
a couple cases where VM hints would be useful for me and how I expect
I'd use them.

---------- Forwarded message ----------

The main problem I've hit is limits on recompilation. In cases where
I'm generating inline caches, dispatchers, etc. It's intended that the
code will need to get recompiled every time it changes. Right now VMs
are designed on the assumption that this is never the case, so v8 and
spidermonkey both stop optimizing that code eventually. That's one
obvious case that I've hit; there are probably others.

An option here might be some simple programmatic assertions (that
could be polyfilled in incompatible browsers) that the JS engine would
have the ability to use as hints, sort of like Math.fround or | 0.
These wouldn't affect observable behavior, just performance (by giving
appropriate hints to the engine).


For example, an IC with a dispatch like this:

function ic (arg1, arg2) {
switch (arg) {
  case xxx: return foo(arg2);
  case yyy: return foo2(arg2);
  case zzz: return x;
  default: return cacheMiss(arg2);
}

maybe you'd hint it like this:

hintedIc = vmHint.inlineCache(ic);
hintedIc(xxx, yyy);

Polyfilled hintedIc would just *be* ic, maybe the call always actually
returns ic. But if the hint were actually implemented it would
basically mean 'assume that any calls through hintedIc are invoking
user-generated inline caches, so recompilation is necessary and
intended and should not disable optimization'.


Similarly:

function add (lhs, rhs) {
  return lhs + rhs;
}

add(1, 2);
add(1.5, 3.5);
add("a", "b");

// whoops, there goes our type info

var addInts = vmHint.cloneCallsite(add);
var addFloats = vmHint.cloneCallsite(add);
var addStrings = vmHint.cloneCallsite(add);

addInts(1, 2);
addFloats(1.5, 3.5);
addStrings("a", "b");

The above would solve a common type info pollution problem in a way
that's backwards compatible (IIRC spidermonkey already has a mechanism
like this, it's just not exposed to user code).


Both of the above optimizations would be useful for JSIL. The callsite
cloning one would likely be a *huge* performance improvement; I have
all the necessary info to maintain a unique callsite for each list of
argument types (since i have static types at compile time).


-kg
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals

Reply via email to