We see quite big blocks allocated by StringBuffer, they should be instrumented.
Created attachment 195572 [details] Patch
Comment on attachment 195572 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=195572&action=review > Source/WTF/wtf/MemoryInstrumentationString.h:77 > + MemoryClassInfo info(memoryObjectInfo, stringBuffer->characters(), 0, sizeof(CharType) * stringBuffer->length()); You have to report the address of stringBuffer and report characters() as the member. if it is a part of memory chunk of stringBuilder then you need to calculate the size for stringBuilder explicitly. See the instrumentation for String.
Comment on attachment 195572 [details] Patch Attachment 195572 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-commit-queue.appspot.com/results/17358068
Created attachment 195730 [details] Patch
(In reply to comment #2) > (From update of attachment 195572 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=195572&action=review > > > Source/WTF/wtf/MemoryInstrumentationString.h:77 > > + MemoryClassInfo info(memoryObjectInfo, stringBuffer->characters(), 0, sizeof(CharType) * stringBuffer->length()); > > You have to report the address of stringBuffer and report characters() as the member. > if it is a part of memory chunk of stringBuilder then you need to calculate the size for stringBuilder explicitly. > See the instrumentation for String. You're right. Fixed.
Comment on attachment 195730 [details] Patch please extract libjpeg change into a separate patch
Created attachment 195738 [details] Patch
Comment on attachment 195738 [details] Patch LGTM
Comment on attachment 195738 [details] Patch Clearing flags on attachment: 195738 Committed r147313: <http://trac.webkit.org/changeset/147313>
All reviewed patches have been landed. Closing bug.