You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Last year @jimmyhmiller and @camnwalter worked on a new interpreter for Rhino. The design is based on instruction objects combined with operands that describe where and how they get their data, but remains primarily stack based like the existing interpreter. So, where we might currently have instructions like this:
REG_INT_C1
LOCAL_LOAD
REG_INT_C2
LOCAL_LOAD
ADD
the new interpreter would have a single Add instruction with two operands for local 1, and local 2. Although the individual instruction objects are significantly large in footprint the operand objects can be heavily reused and the reduced number of instructions makes the memory overhead considerably smaller than might be expected. Performance on some benchmarks is also significantly higher than old interpreter.
I've been working on a set of PRs to integrate these changes which I hope to start push here soon. These will be roughly:
Some refactoring of our test 262 harness to enable running with debug enabled and enabling the addition of new modes ( Run test262 suite with debugger. #2225 ).
Some refactoring of the current interpreter to extract common functionality
Introducing the V2 infrastructure (basic interpreter loop, compiler etc.)
A series of commits to introduce the operands and instructions in a logical order, and in groups small enough to be easily reviewable against the existing interpreter
Enabling the new interpreter
There is also some other potential clean up we could combine with this work where the V2 interpreter has introduced enums instead of lists of static ints for things like function types. Although these changes were originally limited to just the V2 code I'll try to expand any that sense more widely applicable across the codebase. I will also provide full comparative benchmarks.
Last year @jimmyhmiller and @camnwalter worked on a new interpreter for Rhino. The design is based on instruction objects combined with operands that describe where and how they get their data, but remains primarily stack based like the existing interpreter. So, where we might currently have instructions like this:
the new interpreter would have a single
Addinstruction with two operands for local 1, and local 2. Although the individual instruction objects are significantly large in footprint the operand objects can be heavily reused and the reduced number of instructions makes the memory overhead considerably smaller than might be expected. Performance on some benchmarks is also significantly higher than old interpreter.I've been working on a set of PRs to integrate these changes which I hope to start push here soon. These will be roughly:
Contextto use anEvaluationMethodenumerator for choosing between interpreter, interpreter v2, and compilation, and conversion of all tests to use this (IntroduceEvaluationMethodenum to enable the introduction of new interpreter. #2424).There is also some other potential clean up we could combine with this work where the V2 interpreter has introduced enums instead of lists of static ints for things like function types. Although these changes were originally limited to just the V2 code I'll try to expand any that sense more widely applicable across the codebase. I will also provide full comparative benchmarks.