Bug 158668

Summary: Add a mechanism for collecting LLINT stats.
Product: WebKit Reporter: Mark Lam <mark.lam>
Component: JavaScriptCoreAssignee: Mark Lam <mark.lam>
Status: RESOLVED FIXED    
Severity: Normal CC: benjamin, fpizlo, ggaren, keith_miller, msaboff, rniwa, saam
Priority: P2    
Version: WebKit Local Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
proposed patch. fpizlo: review+

Description Mark Lam 2016-06-11 17:08:25 PDT
We currently have no way to count which bytecodes are most popular in the LLINT (except by using the sampling profiler).  This patch will add a mechanism for collecting the stats on LLINT opcode execution counts.
Comment 1 Mark Lam 2016-06-11 17:37:47 PDT
Created attachment 281115 [details]
proposed patch.
Comment 2 Mark Lam 2016-06-13 08:52:44 PDT
Thanks for the review.  Landed in r201990: <http://trac.webkit.org/r201990>.
Comment 3 Ryosuke Niwa 2016-06-17 23:06:41 PDT
It looks like this patch increased our binary size by half a MB. Can we somehow put more stuff inside the compile flag to avoid bloating the binary?
Comment 4 Mark Lam 2016-06-18 00:03:56 PDT
(In reply to comment #3)
> It looks like this patch increased our binary size by half a MB. Can we
> somehow put more stuff inside the compile flag to avoid bloating the binary?

There must be something wrong with the bot that reported this.  Here are the size numbers for comparison.

Method of measurement:
$ size -m WebKitBuild/Release/JavaScriptCore.framework/JavaScriptCore

Size results on x86_64 release builds:

                                r201989     r201990     diff

Segment __TEXT:                 11223040    11223040
    Section __text:             10680261    10680293    +32
    Section __stubs:            2292        2292
    Section __stub_helper:      3796        3796
    Section __const:            218926      218926
    Section __cstring:          256809      256857      +48
    Section __objc_classname:   217         217
    Section __objc_methname:    4461        4461
    Section __gcc_except_tab:   8440        8440
    Section __objc_methtype:    5685        5685
    Section __unwind_info:      35508       35508
    total                       11216395    11216475    +80
Segment __DATA:                 278528      278528
    Section __nl_symbol_ptr:    16          16
    Section __got:              688         688
    Section __la_symbol_ptr:    3056        3056
    Section __const:            128912      128944      +32
    Section __cfstring:         2368        2368
    Section __objc_classlist:   88          88
    Section __objc_catlist:     0           0
    Section __objc_protolist:   8           8
    Section __objc_imageinfo:   8           8
    Section __objc_const:       6296        6296
    Section __objc_selrefs:     1272        1272
    Section __objc_classrefs:   216         216
    Section __objc_superrefs:   48          48
    Section __objc_ivar:        200         200
    Section __objc_data:        880         880
    Section __data:             117096      117096
    Section __bss:              2833        2833
    Section __common:           11720       11776       +56
    total                       275705      275793      +88
Segment __LINKEDIT:             5095424     5095424
total                           16596992    16596992

The data says that we're looking at the __TEXT segment increasing by 80 bytes, and the __DATA segment increasing by 88 bytes.  Based on the changes in the patch, these numbers make sense.  I don't know why the bot thinks there's a half a MB of difference.