Bug #7644
load all legacy enums on FWD server startup
100%
History
#2 Updated by Constantin Asofiei 9 months ago
The legacy enum values are defined as Java 'static final' - and created in a static constructor. The problem here is that we have a cache for the ObjectOps.ObjectHelper
at the object.helper
field. As these fields are static JVM-wide, they will get initialized on whatever FWD context first access them - and will pin that context into memory forever.
A solution would be to override object.isValid
, object.isUnknown
and fix object.compareTo
, so that for an object
instance associated with the static field for a legacy enum, the 'helper' field is never accessed.
#3 Updated by Constantin Asofiei 9 months ago
- % Done changed from 0 to 100
- Assignee set to Constantin Asofiei
- Status changed from New to Review
Created task branch 7644a from trunk rev 14675.
The fix is in rev 14676 - the public static final
field definition is created as a EnumObject
type, which does not save the helper
field. Their initialization can remain as is, when the JVM loads the Java class defining the legacy enum.
#4 Updated by Greg Shah 9 months ago
Code Review Task Brnach 7644a Revision 14676
I don't have an objection, however I do wonder if there is a performance benefit to deferring the ObjectOps.getObjectHelper()
call until the helper is actually used. It would save a context local lookup for any instance that doesn't ever use the helper.
#5 Updated by Constantin Asofiei 9 months ago
Greg Shah wrote:
Code Review Task Brnach 7644a Revision 14676
I don't have an objection, however I do wonder if there is a performance benefit to deferring the
ObjectOps.getObjectHelper()
call until the helper is actually used. It would save a context local lookup for any instance that doesn't ever use the helper.
I need to check, you may be right. I'll do this part of 4032a.
#7 Updated by Constantin Asofiei 9 months ago
Branch 7644a was merged to trunk rev 14676 and archived.