CDV ❯ Auto-detect immutible objects and optimize
-
New Feature
-
Status: Open
-
2 Major
-
Resolution:
-
-
-
prodmgmt
-
Reporter: steve
-
April 15, 2008
-
1
-
Watchers: 2
-
March 19, 2010
-
Description
A couple of levels of this exist but… If an object has no setters outside constructors, or all final fields we can treat it as immutable and not create a shadow object for it. This could greatly improve performance in some use cases.
Comments
Tim Eck 2008-04-15
Steve Harris 2008-04-15
I was actually picturing immutable objects with just literal fields but we might be able to take it further.
We also would have to solve the identity problem So even though we might not need the shadow object we would still need an oid and to store it in a weak hashmap
Taylor Gautier 2008-04-15
Well while you are at it - would you be able to eliminate any (read) synchronization / locking? Seems nutty - maybe only as long as there is no wait/notify it should work.
Also I believe all fields would have to be private - any protected or public would be subject to change outside the class
random thoughts:
maybe I’m missing something, but one purpose of the shadow object is store ObjectID values for unresolved fields. If the immutable type in question only has literal fields, then no TCObject would be needed to store unresolved fields. Of course we could move where the unresolved field map is, but it is in the shadow object at the moment.
It is silly, but depending on the jdk version you can mutate final fields via reflection.
I assume we would still need a field to store a shadow object but perhaps we would re-use some single instance for all of types that qualify for this? Or can the field be eliminated too somehow? We still need to know that the instance is managed or not, right?