Summary: | Dynamic function/type specialisation | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Oliver Hunt <oliver> | ||||||
Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED WORKSFORME | ||||||||
Severity: | Normal | CC: | barraclough, ggaren, mjs, oliver, sam, zwarich | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.5 | ||||||||
Attachments: |
|
Description
Oliver Hunt
2008-08-11 21:50:36 PDT
Created attachment 22741 [details]
initial specialisation patch
Here's an initial version of this patch. Current problems:
* I'm fairly sure it's not gc-safe (it stores the JSFunction* for functions it specialises in the opcode stream, which could be gc'd, then that address could be reallocated with a different object which could in certain circumstances result in badness)
* It's not 64bit safe -- it stores the JSFunction* in a single operand in te intstruction stream.
* Some of the code is heonously ugly, especially the bits where functions specialise themselves.
This code will trigger a failure in commandline jsc: g=Math.sqrt; function f(){return g(4);}; Math.sqrt=null; f(); f(); f(); gc(); for (var i = 0; i < 10000; i++) { g=new Function("", "return 3;"); if (f() == 2) { throw "Failed"; } } Created attachment 22743 [details]
quality test case
We do lots of function & type specialization now; this bug is archaic. |