Experiment: Node properties

[Andy Goryachev]

> What trade off are you making here?  It seems we're trading a small memory gain for more CPU use (extra indirection, walking a list linearly to find the correct property on each use/access VS no indirection, no list walking).

You are right.  The tradeoff is non-zero memory gain (a few megabytes, to the tune of maybe 5% of total heap size) at the cost of extra CPU cycles.  The rationale is that even though we consume extra CPU, it's much less noticeable because of the cache-friendly implementation and non-zero positive impact on garbage collector (less memory to scan).



> Are the resource constrained platforms you named generally memory or CPU constrained?

I asked Gluon for some feedback on iOS/Android.  However, my previous experience with a large trading application says that memory footprint savings outweighs the CPU cycles, so I would imagine we'll get a net gain even on the desktop.



> Have you investigated a breakdown of JavaFX memory use, and did the amount of memory used by properties come out on top here?

There is some statistics provided in https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Experiments/NodeProperties.md , please take a look.



> Would the gains you made here become irrelevant or less relevant with Compact Object Headers [https://openjdk.org/jeps/519]

Compact Object Headers are almost irrelevant here - the stats that were collected count the number of pointers saved (assumed 8 bytes per pointer on 64 bit).  The stats ignore any other possible savings.



> I think the property look-up system cannot reasonably be List (FastMap despite its name is a List). Converting this to a map however is likely to require a small object (like Map.Entry) which will further reduce any gains you made here I think.

The FastMap is a map-like (key-value) storage, even though it's implemented as an array.  There is a debate as to what would the most efficient implementation entail (a hashmap, one array, or two arrays like the POC currently uses).  The idea is not to put all​ the properties into the container, but only the rarely used ones, with the end result of having a few (less than 4-6, say).  This makes the object small and cache-friendly, which further speeds up the access.


Thanks!

-andy




From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Thursday, February 19, 2026 at 15:28
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Experiment: Node properties



On 04/02/2026 22:17, Andy Goryachev wrote:
I would like to share the results of a little experiment involving optimization of storage of Node properties.  The basic idea is to create a compact fast map-like container to hold the rarely instantiated properties in order to reduce the application memory footprint.

The savings are not overwhelming, but not exactly zero.  I would imagine this optimization might be more interesting in any resource constrained environment such as Android / iOS / RaspberryPi.  Please refer to [0] for the details.

What trade off are you making here?  It seems we're trading a small memory gain for more CPU use (extra indirection, walking a list linearly to find the correct property on each use/access VS no indirection, no list walking).

Are the resource constrained platforms you named generally memory or CPU constrained?

Have you investigated a breakdown of JavaFX memory use, and did the amount of memory used by properties come out on top here?

Would the gains you made here become irrelevant or less relevant with Compact Object Headers [https://openjdk.org/jeps/519]


I encourage you to try it with your application, to see whether you notice any change in memory consumption and/or performance.  Let me know what you think!

I like the idea, but I wonder if there really is much to gain here, and whether those gains will hold up with future Java improvements.

I think the property look-up system cannot reasonably be List (FastMap despite its name is a List). Converting this to a map however is likely to require a small object (like Map.Entry) which will further reduce any gains you made here I think.

--John

Cheers,
-andy


References

[0] https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Experiments/NodeProperties.md

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20260223/148d3e22/attachment-0001.htm>