-
Enhancement
-
Resolution: Not an Issue
-
P2
-
None
-
9
-
None
-
generic
-
generic
(ported from kenai to keep the info).
Original CR info preserved (this is not exactly how we will do it - it will instead sit on top of RecompilableScriptFunctionData)
Every toObject conversion everywhere in the code is our enemy.
We should revisit the early prototype for method specialization
Don't generate any explicit revert stubs anymore. Use method handle converters
Use method Id to guard on, instead of logic in checkFunction
Decide what to specialize and where. We can specialize functions both on their call sites and on what their parameters actually turn into in the IR. The latter is probably easier at first and provides us with one decent specialization.
--
another problem with call specialization is that you really have no idea what a.b[x](double, double) is at compile time
[9/19/12 1:54:05 PM] Marcus Lagergren: we should do the toObject conversion only at the receiver if necessary, not at the callsite
---
Let it be forever known here so I don't fall into this mental trap one more time:
function square(a) {
return a * a;
}
generates to:
method(O, O)
aload 0
toNumber
aload 1
toNumber
dmul
dreturn
We would be tempted to generate it as
method(D D)
dload 0
dload 2
dmul
dreturn
as we know nothing is done with the parameters that isn't first casting them to a double, or rather executing a toNumber function.
One might be tempted to implement the generic version as
method(O O)
call square method handle (toNumber(O), toNumber(O))
But this won't work.
toNumber maybe ha side effects if someone passes an object with an overwritten valueOf. This can basically do anything.
Thus param1*param1 can NEVER be anything else than toNumber(param1)*toNumber(param2).
It's as if Brendan Eich manually removed any optimization opportunities in this language.
We CAN specialize if we generate a double version of the method and a separate object version of the method, in effect doubling code bloat.
This is probably not feasible in the generic case, and as there is no way to know most of callsite -> callee mappings at compile time this will be problematic.
I still see some limited things that can be done in this space and I will document their progress here.
Original CR info preserved (this is not exactly how we will do it - it will instead sit on top of RecompilableScriptFunctionData)
Every toObject conversion everywhere in the code is our enemy.
We should revisit the early prototype for method specialization
Don't generate any explicit revert stubs anymore. Use method handle converters
Use method Id to guard on, instead of logic in checkFunction
Decide what to specialize and where. We can specialize functions both on their call sites and on what their parameters actually turn into in the IR. The latter is probably easier at first and provides us with one decent specialization.
--
another problem with call specialization is that you really have no idea what a.b[x](double, double) is at compile time
[9/19/12 1:54:05 PM] Marcus Lagergren: we should do the toObject conversion only at the receiver if necessary, not at the callsite
---
Let it be forever known here so I don't fall into this mental trap one more time:
function square(a) {
return a * a;
}
generates to:
method(O, O)
aload 0
toNumber
aload 1
toNumber
dmul
dreturn
We would be tempted to generate it as
method(D D)
dload 0
dload 2
dmul
dreturn
as we know nothing is done with the parameters that isn't first casting them to a double, or rather executing a toNumber function.
One might be tempted to implement the generic version as
method(O O)
call square method handle (toNumber(O), toNumber(O))
But this won't work.
toNumber maybe ha side effects if someone passes an object with an overwritten valueOf. This can basically do anything.
Thus param1*param1 can NEVER be anything else than toNumber(param1)*toNumber(param2).
It's as if Brendan Eich manually removed any optimization opportunities in this language.
We CAN specialize if we generate a double version of the method and a separate object version of the method, in effect doubling code bloat.
This is probably not feasible in the generic case, and as there is no way to know most of callsite -> callee mappings at compile time this will be problematic.
I still see some limited things that can be done in this space and I will document their progress here.
- blocks
-
JDK-8010702 Revisit --dual-fields
- Closed
- is blocked by
-
JDK-8010701 Immutable IR - part 2
- Resolved