Project

General

Profile

Bug #7644

load all legacy enums on FWD server startup

Added by Constantin Asofiei 9 months ago. Updated 9 months ago.

Status:
Test
Priority:
Normal
Target version:
-
Start date:
Due date:
% Done:

100%

billable:
No
vendor_id:
GCD
case_num:

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.

#6 Updated by Greg Shah 9 months ago

If you want to merge 7644a to trunk, you can go ahead.

#7 Updated by Constantin Asofiei 9 months ago

Branch 7644a was merged to trunk rev 14676 and archived.

#8 Updated by Greg Shah 9 months ago

  • Status changed from Review to Test

Also available in: Atom PDF