Project

General

Profile

Support #4657

memory overhead from preloading classes with LegacySignature

Added by Greg Shah about 4 years ago. Updated about 4 years ago.

Status:
WIP
Priority:
Normal
Assignee:
Constantin Asofiei
Target version:
-
Start date:
Due date:
% Done:

60%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:

History

#1 Updated by Greg Shah about 4 years ago

  • Subject changed from heap overhead from preloading classes with LegacySignature to memory overhead from preloading classes with LegacySignature

When the server starts, the SourceNameMapper.initMappingData() will walk the name map and load all of the converted classes that have @LegacySignature annotations. This results in every converted class (procedure or OO class) having its class loaded and any static initialization executed.

My concern here is that for large projects, this will cause a substantial amount of memory usage. In Java 8 and above, the metaspace (replacement for permgen) is in native memory instead of the heap AND it grows without bound by default. It seems likely to me that for most applications we will be loading many converted classes that would not otherwise be loaded in the lifetime of the server.

I am wondering if the cost is worth the benefit here OR if alternatively, we should implement lazy loading.

#2 Updated by Constantin Asofiei about 4 years ago

Theoretically, all converted classes will be loaded at some point, considering the application usage and a very-long-running FWD application server. So the heap usage (be it at server startup or during FWD server uptime) remains the same.

My goal with LegacySignature is to leave the name_map.xml only as a registry for legacy classes and external programs (plus 'virtual' functions/procedures - the in super and in handle). My opinion is that this allows the project to be better maintained in Java, than editing some 300MB name_map.xml file (for large projects)

Greg Shah wrote:

... OR if alternatively, we should implement lazy loading.

I'll look into lazy loading.

#3 Updated by Constantin Asofiei about 4 years ago

  • Start date deleted (05/28/2020)
  • Status changed from New to WIP
  • Assignee set to Constantin Asofiei
  • % Done changed from 0 to 60

The lazy loading approach for external programs case is fixed in 4231b rev 11584

For legacy classes, they are all loaded at server startup. A lazy approach is a little complicated, with the overloads and such. But I'll look into it, too.

#4 Updated by Greg Shah about 4 years ago

Task branch 4231b has been merged to trunk as revision 11347.

Also available in: Atom PDF