Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8170467

(reflect) Optimize SignatureParser's use of StringBuilders





        Max-Kanat Alexander (mkanat@google.com) writes:

        Currently, any heavy use of sun.reflect.generics.parser.SignatureParser
        leads to many calls to Arrays.copyOf, due to using StringBuilder inside of
        SignatureParser to build up a string a character at a time. This showed up
        as a top CPU-usage culprit in profiling of a large number of tests,
        particularly those which use reflection-heavy dependency injection systems
        such as Guice.

        To determine the size to pre-size the StringBuilder in this patch, I made
        AbstractStringBuilder.expandCapacity print out the original capacity and
        new capacity every time it did a resize. I measured the outputs that
        happened during a heavy real-world user of SignatureParser, and took
        particular measurements at different StringBuilder sizes:

            16: Reallocs: 907310 Total Alloc Counting Only Realloc: 84324048
        Estimated Total Alloc: 84310608 Copy Bytes: 27249937 Reallocs from initial
        size: 517883
            32: Reallocs: 497220 Total Alloc Counting Only Realloc: 68184799
        Estimated Total Alloc: 75412799 Copy Bytes: 22138274 Reallocs from initial
        size: 291168
            40: Reallocs: 331045 Total Alloc Counting Only Realloc: 54170531
        Estimated Total Alloc: 69096811 Copy Bytes: 17560068 Reallocs from initial
        size: 143886
            48: Reallocs: 222232 Total Alloc Counting Only Realloc: 42141244
        Estimated Total Alloc: 65213692 Copy Bytes: 13637722 Reallocs from initial
        size: 36367
            56: Reallocs: 196595 Total Alloc Counting Only Realloc: 39246690
        Estimated Total Alloc: 67601618 Copy Bytes: 12698496 Reallocs from initial
        size: 10705
            64: Reallocs: 185941 Total Alloc Counting Only Realloc: 38031623
        Estimated Total Alloc: 71112263 Copy Bytes: 12304703 Reallocs from initial
        size: 158

        As you can see, 48 gives us the lowest total memory allocation as well as
        significantly reducing the number of times we reallocate arrays. With
        higher values it becomes significantly non-linear in improvement and we
        start to allocate more memory overall, so 48 seemed like the right number
        to pick.


          Issue Links



                redestad Claes Redestad
                redestad Claes Redestad
                0 Vote for this issue
                4 Start watching this issue