RFR: 8290040: Provide simplified deterministic way to manage listeners [v6]

[Nir Lisker]

On Tue, 18 Oct 2022 17:47:38 GMT, Michael Strauß <mstrauss at openjdk.org> wrote:

>> I'd respectfully disagree: in a large application, there might be hundreds (a thousand?) Nodes, and only a handful (10-20?) Nodes with this property (2%), so it's a waste of RAM.  One may think it's only 8Kb on a 64 bit machine, but it does add up quickly.  Even the access pattern is basically 'get it once to establish the fluent pipeline', with no more calls to the Node accessor (unlike MiscProperties constituents, some of which get accessed rather frequently).
>
>> I'd respectfully disagree: in a large application, there might be hundreds (a thousand?) Nodes, and only a handful (10-20?) Nodes with this property (2%), so it's a waste of RAM. One may think it's only 8Kb on a 64 bit machine, but it does add up quickly. Even the access pattern is basically 'get it once to establish the fluent pipeline', with no more calls to the Node accessor (unlike MiscProperties constituents, some of which get accessed rather frequently).
> 
> I understand your point, but I don't think that this is sufficient reason to introduce a new way of storing property instances in an ad-hoc manner. If memory consumption is a concern, I would rather analyze the issue in a separate enhancement proposal, think it through in terms of API, and then transition all relevant property instances to the new storage mechanism. Part of that proposal should also be an evaluation of the trade-offs between memory consumption and performance in terms of cache locality and lookup speed.

`getProperties()` isn't the place for this. After looking at the grouping of properties, there might be merit to reevaluate the distribution of properties into their helper classes in the case that a single use of a common property will create many other unused ones.

As for RAM usage, Hotspot can compress pointers on a 64bit machine. I don't think that the change in memory here will be more significant than in other areas in `Node` that can be addressed.

-------------

PR: https://git.openjdk.org/jfx/pull/830