[Webkit-unassigned] [Bug 79899] DFG BasicBlocks should not require that their nodes have contiguous indices in the graph

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=79899





--- Comment #4 from Filip Pizlo <fpizlo at apple.com>  2012-02-29 18:39:12 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > 
> > My guess: the HashMap you added to AbstractState.
> > 
> > My original implementation had a Vector<AbstractValue> indexed by NodeIndex rather than NodeIndex - m_block->begin.  But my original implementation also had loads of regressions, which turned out to be because of a combination of clobberStructures() (that's why I have that m_haveStructures and the hacks to make clobberStructures() walk over fewer things).  In the process, I also changed the Vector to be indexed by NodeIndex offset from block begin, but I have no idea if that change improved performance at all.
> > 
> 
> Yes, you're right. If we still maintain the abstract values in a Vector and index them by NodeIndex then there's no such performance regression. However it may use more memory as the vector size is equal to the graph size. Do you think it's an acceptable tradeoff?

That's great!  I think that this is a perfectly acceptable tradeoff.

Here's my specific thinking:

- The old JIT is emitting ~100 bytes of machine code for basic arithmetic instructions, and probably no less than ~20 bytes of any other instruction.  Some instructions emit drastically more than 100 bytes.  So long as the DFG's footprint per bytecode instruction (with on average two DFG nodes - the operation and the SetLocal - per bytecode instruction) is less than 100, we probably shouldn't worry.  I think we're already over this by the way, but probably not by much.

- The DFG::Node class currently has ~8 32-bit words of junk.  Here we're adding 2 64-bit words to represent the AbstractValue.  So this is a small regression.

- The DFG should be allowed to make a space-time trade-off if needed, and also, a space-teamProductivity trade-off as well.  We only invoke the DFG rarely.  We only invoke the DFG for code that is not absurdly big.  And when we do invoke it, there is only one instance of the DFG running at a time.  Hence it should be allowed to use some extra memory if it's beneficial for performance, or if it makes the code easier for us to hack.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.