See JDK-8182769.
"""
There's also an issue with string concatenation nodes: it is not too
infrequent to have very very long string concat chains. The current
strategy is to turn string concat into a binary op, which means you need
N -1 nested nodes to chain N strings together. It's not much of a
problem in terms of memory as it is in terms of stack traces: the stack
you need to visit a string concat grows with the number of elements
being concatenated. It is not uncommon to get stack overflows on string
concatenation. The compiler currently has few hacks in place to try and
combine things together as much as possible (one attempt is done in
Parser, another is done in Attr/ConstFold) - but this is very brittle
and bad for IDEs which then lose correspondency with original source
positions.
"""
"""
There's also an issue with string concatenation nodes: it is not too
infrequent to have very very long string concat chains. The current
strategy is to turn string concat into a binary op, which means you need
N -1 nested nodes to chain N strings together. It's not much of a
problem in terms of memory as it is in terms of stack traces: the stack
you need to visit a string concat grows with the number of elements
being concatenated. It is not uncommon to get stack overflows on string
concatenation. The compiler currently has few hacks in place to try and
combine things together as much as possible (one attempt is done in
Parser, another is done in Attr/ConstFold) - but this is very brittle
and bad for IDEs which then lose correspondency with original source
positions.
"""
- blocks
-
JDK-8182769 Parser - better nodes for string concat and enums
- Open
- relates to
-
JDK-8162710 SOE for nested String.concat calls
- Closed