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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Aug 28 07:43:45 PDT 2012


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





--- Comment #26 from Yong Li <yoli at rim.com>  2012-08-28 07:43:46 PST ---
(In reply to comment #25)
> > I tried making X86Assmebler work with the new AssemblerBuffer. But there are too many dependencies on the flat consecutive buffer. I guess probably more than half of the source code will be changed.
> 
> I'd suggest there is probably a really quick fix you could try here.  In the X86Assembler, do two quick find & replaces to remove the following:
>     "m_buffer.ensureSpace(maxInstructionSize);" -> ""
>     "Unchecked" -> ""
> This will add a few extra bounds checks, but the benefit from your patch should more than balance this out.
> 

That's what I've tried. But there are many places it directly works on raw addresses in the buffer... I'm afraid solving all of this ends up with performance penalty... Also X86 system usually has a lot of memory (vm space) to consume... I would prefer OSAllocator/mmap to segmented vector on x86.

> > Speaking of assemblers, there is already another AssemblerBuffer for ARM (traditional): AssemblerBufferWithConstantPool.
> 
> No, ARM doesn't use a different AssemblerBuffer – if you look you'll see that AssemblerBufferWithConstantPool is actually a subclass of AssemblerBuffer – all assemblers use the same implementation of AssemblerBuffer, we just happen to use inheritance as a part of how we structure the code to share the constant pool used by ARM traditional & SH4.

We have different assembler/MacroAssembler anyway. And there is #ifdef even in LinkBuffer.cpp. So a specific assembler using a different buffer internally doesn't look so bad to me. But probably it would be better to change buffer() function to getData() so the buffer is fully hidden in assembler implementation.

-- 
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