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

Back out JDK-6976350 since it does not fix any issue



    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 8u20, 9
    • Fix Version/s: 9
    • Component/s: hotspot
    • Subcomponent:
    • Resolved In Build:



        JDK-6976350 changed the PLAB allocation to use two buffers per thread instead of one with the intent of decreasing PLAB waste.

        Recently we have analyzed some high-thread, high-fragmentation inducing applications (many different object sizes used) as part of JDK-8030849, and seen a few applications behaving worse than without that patch.

        In particular, specjbb2013 and CRM Fuse with many threads (few hundred for specjbb) run significantly faster without that change.

        Attached a few figures to show the "difference" between the two versions in more detail on some dacapo benchmarks.

        backout_dacapo_overall.png shows total PLAB buffer use for all DaCapo benchmarks (on the x-axis; t04 means with 4 GC threads, bX means that X number of buffers were used). Results with one and two buffers are shown interleaved. Y-axis shows the number of bytes used by PLAB allocation, divided into allocation of objects (blue), waste at the end of the PLAB buffers (red) and unused space at the end of PLABs because of unfilled buffers at the end of GC.

        The figure basically shows no real difference across applications, sometimes one or the other is ahead in space used.

        backout-eclipse|tradesoap-increasing-threads.png and backout-eclipse/tradesoap-increased-threads-gc.png show more detail for the eclipse and tradesoap benchmarks respectively.

        The first figure (backout-eclipse|tradesoap-increasing-threads.png) show the amount of PLAB allocation for eclipse when increasing the number of parallel gc threads from 1 to 32. The left half of the figure shows the behavior when using a single buffer, the right half when using two buffers.

        There is *no* real difference at all.

        backout-eclipse/tradesoap-increased-threads-gc.png show the number of GCs and total allocated bytes with an increasing number of threads. Again, on the left, using one buffer (original code) and on the right using two buffers.

        Again, no significant difference.

        Since the change effects nothing for these applications (and we have numbers for larger applications which show a slight disadvantage of using two buffers), and this change did not implement the idea suggested in JDK-6976350, this code just complicates the codebase.


            Issue Links



                tschatzl Thomas Schatzl
                tschatzl Thomas Schatzl
                0 Vote for this issue
                3 Start watching this issue