As part of JDK-8345302, it was determined the end pos tables may consume considerable amounts of memory. It should be investigated if the memory consumption can be reduced when preserving end positions.
Possible options include:
- stop using the end pos table, and store the end positions directly in JCTree
- avoid using the end pos table when the end positions can be resonably computed from the primary position ("JCTree.pos") - like for a typical primitive type, where the end position is typically "pos + len(<type-name>)", or potentially for JCVariableDecl, where the end pos could be possibly computed from the position, name length, initializer end position and the presence or absence of the closing ';'.
- reducing the speed by which IntHashTable re-allocates its internal tables, increasing density of the data stored in the tables.
Possible options include:
- stop using the end pos table, and store the end positions directly in JCTree
- avoid using the end pos table when the end positions can be resonably computed from the primary position ("JCTree.pos") - like for a typical primitive type, where the end position is typically "pos + len(<type-name>)", or potentially for JCVariableDecl, where the end pos could be possibly computed from the position, name length, initializer end position and the presence or absence of the closing ';'.
- reducing the speed by which IntHashTable re-allocates its internal tables, increasing density of the data stored in the tables.
- relates to
-
JDK-8345302 Building microbenchmarks require larger Java heap
-
- Resolved
-