This have certainly progressed since October!

We now have well over half the nodes in the AST being interpreted in a
purely iterative style. Where those nodes used to deepen the Java
stack by many frames (n multiples of 3 or 4 per node) they now are
processed and forgotten by JRuby, steadily increasing our maximum Ruby
stack depth and bringing us closer to fully-functional
Frames-as-partial-continuations.

The text below details the status of conversion of all these nodes.
There are 39 unconverted as opposed to 46 converted, but many of the
unconverted require only a bit of examination or a minimal amount of
work. A large number of them are considered incomplete because they
throw exceptions (which may actually "just work" with the new event
model) and others because they make function/method calls (which will
all be pulled out as the last step in "iteratizing" the interpreter).
There's work to do, but the path is clearer.

--
Node evaluation, report on conversion to iterative style

Incomplete (39):
AliasNode - method call to method_added must be pulled out
BackRefNode - makes native method calls, but they may be leaves
BlockPassNode - multiple evaluations take place to build the block as
well as exceptions, method calls, and TC manip
ConstDeclNode - almost done, but throws an exception...may still be
finished though
ClassVarNode - unworked, but maybe nothing to do
CallNode - obviously incomplete; args eval, method call must be pulled out
CaseNode - really big, multiple evals and method calls but no exceptions
ClassNode - also big, plus significant eval, method calls, TC manip
Colon2Node - almost done, other than a method call
Colon3Node - probably done, but should check getConstant for any
deepening of stack
ConstNode - ditto
DXStrNode - using stack-based result agg; done except for method call
DefinedNode - problematic; uses a second node visitor for "defined"
checking which has not been refactored
DefnNode - big, TC manip, method calls, exceptions
DefsNode - ditto
FCallNode - args eval, method call must be pulled out
FlipNode - unworked; many evals, but not otherwise terribly complex
ForNode - problematic, because it's both a language construct and
causes a block creation
IterNode - multiple evals, exceptions, TC manip
MultipleAsgnNode - problematic; uses a second node visitor that hasn't
been converted
Match3node - using stack-based result agg; complete except for method call
ModuleNode - big; comparable to ClassNode
NthRefNode - probably done, but makes a (possibly leaf) method call
OpElementAsgnNode - multiple evals
OpAsgnNode - multiple evals
SClassNode - comparable to ClassNode
ScopeNode - TC manip, try/finally stuff
StrNode - done except for concerns about IRuby.newString causing stack deepen
SuperNode - exceptions, args eval, try/finally
UndefNode - exceptions
VCallNode - method call
XStrNode - method call
YieldNode - like a method call
ZCallNode - like a method call
BignumNode - nothing to do, but examine creation side effects
FixnumNode - ditto
FloatNode - ditto
RegexpNode - ditto
SymbolNode - ditto

Complete (46):
AndNode
ArgsCatNode - using stack-based result agg
ArrayNode - using stack-based result agg
BeginNode
BlockNode
BreakNode - using new event model
ClassVarAsgnNode
ClassVarDeclNode
DAsgnNode
DRegexpNode - using stack-based result agg
DStrNode - using stack-based result agg
DSymbolNode - using stack-based result agg
DVarNode - nothing to do
DotNode - using stack-based result agg
EnsureNode - using new event model
FalseNode - nothing to do
GlobalAsgnNode
GlobalVarNode
HashNode - using stack-based result agg
InstAsgnNode
InstVarNode - nothing to do
IfNode
LocalAsgnNode
LocalVarnode - nothing to do
Match2Node - using stack-based result agg
MatchNode
NewlineNode
NextNode - using new event model
NoopNode - duh
NotNode
OptNNode - using new event model
OrNode
RedoNode
RescueBodyNode
RescueNode
RetryNode
ReturnNode
SelfNode - nothing to do
SplatNode
SValueNode
ToAryNode
TrueNode - nothing to do
UntilNode - using new event model
VAliasNode - nothing to do
WhileNode - using new event model
ZArrayNode
--

- Charlie


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Jruby-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jruby-devel

Reply via email to