[Webkit-unassigned] [Bug 94712] High memory usage spike in AssemblerBuffer

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Aug 31 12:45:33 PDT 2012


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





--- Comment #33 from Yong Li <yoli at rim.com>  2012-08-31 12:45:41 PST ---
(In reply to comment #32)
> (From update of attachment 161564 [details])
> We work very hard to keep the JIT cross platform.  This change is great, but we are concerned about peak memory usage on x86 too, there is absolutely no justification to fork the AssemblerBuffer here, and to do so will detrimental to the long term maintainability of the project.  If I have time I'll try to look at what the problem is you're having on x86, and see if I am able to give you any further advice to to try to take this patch to completion as efficiently as possible.

I understand JIT should be cross-platform as long as possible. But we still have platform-specific code when needed, like ENABLE(BRANCH_COMPACTION) in LinkBuffer.cpp, which is actually only used by CPU(ARM_THUMB2). The most important thing is unlike LinkBuffer, AssemberBuffer is even below the platform-specific layer, and far way from the cross-platform part in JIT.

1-Cross-platform code
2-MacroAssember<CPU>
3-<CPU>Assmbler
4-AssemblerBuffer

Which AssemberBuffer to use in a specific assembler can be (if not now) made totally transparent to higher layer. Also I am not saying we cannot share the same AssemblerBuffer between assemblers in longer term. But why cannot we make other assemblers follow up in subsequent tasks?

That said, I'm also considering another solution, using OSAllocator, which will keep the buffer consecutive as it is, so work with all assemblers. However I'm not sure every platform is OK to reserve a huge virtual memory space, let's say 32MB. Any idea please?

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


More information about the webkit-unassigned mailing list