This was discovered while testing the fix for JDK-8349105. The following simple loop will cause a reasonably significant memory leak:

       for (int i = 0; i < 5000; i++) {
            int mx = 2 + i % 100;
            c.setPageCount(mx);
            c.setCurrentPageIndex(i % mx);
        }

To reproduce, :
1. Run the attached program
2. Attach visual_vm
3. Press GC: note that the memory doesn't decrease
4. Take a heap dump

While you will see only one instance of Pagination and PaginationSkin, there are over 80,000 PaginationSkin$IndicatorButton instances (with a similar number of HashMap instances, etc).


## Root Cause

Each time a PaginationSkin.IndicatorButton gets created it adds two listeners (to the control's styleClass property and to the skin's tooltipVisible property) via ListenerHelper. This was not detected by the SkinMemoryLeakTest because all listeners got removed correctly upon skin change.

## Solution

Add a single listener to the control's `styleClass` property at the skin level, and insert the call to the skin's `tooltipVisible` property both of which iterate over indicator button to do their thing.