JDK-8162704 : deeply nested expression stumps the compiler-checking algorithm
- Type: Bug
- Component: tools
- Sub-Component: javac
- Affected Version: 8
- Priority: P4
- Status: Resolved
- Resolution: Duplicate
- OS: linux
- CPU: x86_64
- Submitted: 2016-07-26
- Updated: 2017-02-14
- Resolved: 2017-02-14
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
To download the current JDK release, click here.
| JDK 10 |
|---|
10Resolved  |
Related Reports
|
Duplicate :
|
|
|
Relates :
|
Description
A DESCRIPTION OF THE REQUEST :
for generated code of the form (A.concat(B)).concat(C.concat(D))
which forms a balanced tree but much deeper
where the leafs all of the same form and the leafs are of the form new CharString(RB, <string_literal>)
seems to break the checking algorithm of Javac from JAVA SE 8
While the code is successfully compilable in Java 7 in 2-3 seconds, Javac 8 does not finish checking in over 90 minutes! (I have not checked this further and I am not sure whether it will finish at all or run out of resources)
JUSTIFICATION :
If the compiler even finishes, this would be a huge performance loss for a very simple case of code.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The performance should be comparable to the one in earlier versions of javac.
ACTUAL -
When running javac with -verbose, the last statement printed is: [checking TTCN3_spv_nos].
One CPU is used to the maximum, memory is used and freed continually (when monitoring the process with jvisualvm). Reserved memory on the process level continually increases.
Unfortunately, it is only reproducible when using our runtime library which that generated code is compiled against. I would provide this in jar-form, if requested.
When replacing the imported classes with local classes, the problem does not occur, so it might have to do something with name resolution.
I have whittled the original example down to something where the javac 8 only takes 10 times more time than javac 7, but the performance loss does not seem to be linear to the size of the input, but either polynomial or even exponential.
---------- BEGIN SOURCE ----------
import java.util.Arrays;
import java.util.Collection;
import java.math.BigInteger;
import java.math.BigDecimal;
import de.tu_berlin.cs.uebb.ttcn.runtime.*;
import de.tu_berlin.cs.uebb.ttcn.runtime.Void;
import de.tu_berlin.cs.uebb.muttcn.runtime.*;
import de.tu_berlin.cs.uebb.muttcn.runtime.Float;
import de.tu_berlin.cs.uebb.ttcn.runtime.continuous.*;
import de.tu_berlin.cs.uebb.muttcn.runtime.Module;
import com.testingtech.ttcn.tci.ExtendedTciTypeClass;
import com.testingtech.ttcn.tciext.EnumeratedType;
import org.etsi.ttcn.tci.Type;
import org.etsi.ttcn.tci.Value;
import org.etsi.ttcn.tci.IntegerValue;
import de.tu_berlin.cs.uebb.muttcn.runtime.RB;
public class TTCN3_spv_nos_small1 extends ModuleEnvironment {
public static CharString TTCN3_spv_nos;
public
TTCN3_spv_nos_small1(final RB RB, final Module module) {
super(RB, module);
TTCN3_spv_nos =
new
CharString(RB,
"")
.concat(new CharString(RB, ""))
.concat(new
CharString(RB,
"")
.concat(new CharString(RB, "")))
.concat(new CharString(RB, "")
.concat(new
CharString(RB,
""))
.concat(new
CharString(RB,
"")
))
.concat(new
CharString(RB, "")
.concat(new
CharString(RB,
"")
.concat(new
CharString(RB,
""))
.concat(new
CharString(RB,
"")
.concat(new
CharString(RB,
"")))
.concat(new
CharString(RB,
"")
.concat(new
CharString(RB,
""))
.concat(new
CharString(RB,
"")
.concat(new
CharString(RB,
"")
.concat(new
CharString(RB,
""))))
.concat(new
CharString(RB,
"")
.concat(new
CharString(RB,
""))
.concat(new
CharString(RB,
"")
.concat(new
CharString(RB,
"")
.concat(new
CharString(RB,
""))))
.concat(new
CharString(RB,
"")
.concat(new
CharString(RB,
""))
.concat(new
CharString(RB,
"")
.concat(new
CharString(RB,
"")
.concat(new
CharString(RB,
""))))
.concat(new
CharString(RB,
"")
.concat(new
CharString(RB,
""))
.concat(new
CharString(RB,
"")
.concat(new
CharString(RB,
"")
.concat(new
CharString(RB,
""))))))))));
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
I will generate the code in a different way so that literal strings are concatenated already at compile-time. For my special case, this will solve the problem.
Comments
|