RFR: JDK-8199216: Memory leak and quadratic layout time with nested nodes (hbox) and pseudo-class in style sheet
Marius Hanl
mhanl at openjdk.org
Thu Mar 30 17:19:26 UTC 2023
On Thu, 30 Mar 2023 12:49:39 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:
> This fix introduces immutable sets of `PseudoClass` almost everywhere, as they are rarely modified. These are re-used by caching them in a new class `ImmutablePseudoClassSetsCache`.
>
> In order to make this work, `BitSet` had to be cleaned up. It made assumptions about the collections it is given (which may no longer always be another `BitSet`). I also added the appropriate null checks to ensure there weren't any other bugs lurking.
>
> Then there was a severe bug in `toArray` in both the subclasses that implement `BitSet`.
>
> The bug in `toArray` was incorrect use of the variable `index` which was used for both advancing the pointer in the array to be generated, as well as for the index to the correct `long` in the `BitSet`. This must have resulted in other hard to reproduce problems when dealing with `Set<PseudoClass>` or `Set<StyleClass>` if directly or indirectly calling `toArray` (which is for example used by `List.of` and `Set.of`).
>
> The net result of this change is that there are far fewer `PseudoClassState` objects created; the majority of these are never modified, and the few that are left are where you'd expect to see them modified.
>
> A test with 160 nested HBoxes which were given the hover state shows a 99.99% reduction in `PseudoClassState` instances and a 70% reduction in heap use (220 MB -> 68 MB), see the linked ticket for more details.
>
> Although the test case above was extreme, this change should have positive effects for most applications.
One more optimization we could have a look at is too create the `BitSet` or related subclasses with a predefined size, so we don't need to grow the `long[] bits` array too often. `PseudoClassState` already has a constructor that accepts another collection, but can not use this information to create a bigger `bits` array.
(Like e.g. the `ArrayList` or `HashSet` constructor)
modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 227:
> 225: final T t = cast(o);
> 226:
> 227: if (t == null) { // if cast failed, it can't be part of this set
If I understand the code correctly, this can't happen right now, right?
modules/javafx.graphics/src/main/java/com/sun/javafx/css/BitSet.java line 231:
> 229: }
> 230:
> 231: final int element = getIndex(t) / Long.SIZE;
`getIndex(t)` is called twice here and below, maybe we should consider calling it once and save the result in a local variable instead?
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1076#issuecomment-1490264725
PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1153276734
PR Review Comment: https://git.openjdk.org/jfx/pull/1076#discussion_r1153274025
More information about the openjfx-dev
mailing list