Skip to content

Commit 3222807

Browse files
committed
[core] Fix memory usage regression in CPD (#5090)
Merge pull request #5090 from Monits:issue-5066
2 parents 06ba547 + a9d43d0 commit 3222807

File tree

2 files changed

+5
-4
lines changed

2 files changed

+5
-4
lines changed

docs/pages/release_notes.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -40,6 +40,7 @@ See also [Maven PMD Plugin]({{ baseurl }}pmd_userdocs_tools_maven.html).
4040
* [#2827](https://github.com/pmd/pmd/issues/2827): \[cli] Consider processing errors in exit status
4141
* core
4242
* [#4992](https://github.com/pmd/pmd/pull/4992): \[core] CPD: Include processing errors in XML report
43+
* [#5066](https://github.com/pmd/pmd/issues/5066): \[core] CPD throws java.lang.OutOfMemoryError: Java heap space (since 7.1.0)
4344
* apex
4445
* [#4922](https://github.com/pmd/pmd/issues/4922): \[apex] SOQL syntax error with TYPEOF in sub-query
4546
* [#5053](https://github.com/pmd/pmd/issues/5053): \[apex] CPD fails to parse string literals with escaped characters

pmd-core/src/main/java/net/sourceforge/pmd/cpd/MatchCollector.java

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -68,15 +68,15 @@ private void reportMatch(TokenEntry mark1, TokenEntry mark2, int dupes) {
6868
* - BC
6969
* It should be reduced to a single match with 3 marks
7070
*/
71-
if (tokenMatchSets.computeIfAbsent(mark1.getIndex(), HashSet::new).contains(mark2.getIndex())) {
71+
if (tokenMatchSets.computeIfAbsent(mark1.getIndex(), (i) -> new HashSet<>()).contains(mark2.getIndex())) {
7272
return;
7373
}
7474

7575
// This may not be a "new match", but actually a sub-match of a larger one.
7676
// always rely on the lowest mark index, as that's the order in which process them
7777
final int lowestKey = tokenMatchSets.get(mark1.getIndex()).stream().reduce(mark1.getIndex(), Math::min);
7878

79-
List<Match> matches = matchTree.computeIfAbsent(lowestKey, ArrayList::new);
79+
List<Match> matches = matchTree.computeIfAbsent(lowestKey, (i) -> new ArrayList<>());
8080
Iterator<Match> matchIterator = matches.iterator();
8181
while (matchIterator.hasNext()) {
8282
Match m = matchIterator.next();
@@ -116,8 +116,8 @@ private void reportMatch(TokenEntry mark1, TokenEntry mark2, int dupes) {
116116
}
117117

118118
private void registerTokenMatch(TokenEntry mark1, TokenEntry mark2) {
119-
tokenMatchSets.computeIfAbsent(mark1.getIndex(), HashSet::new).add(mark2.getIndex());
120-
tokenMatchSets.computeIfAbsent(mark2.getIndex(), HashSet::new).add(mark1.getIndex());
119+
tokenMatchSets.computeIfAbsent(mark1.getIndex(), (i) -> new HashSet<>()).add(mark2.getIndex());
120+
tokenMatchSets.computeIfAbsent(mark2.getIndex(), (i) -> new HashSet<>()).add(mark1.getIndex());
121121
}
122122

123123
List<Match> getMatches() {

0 commit comments

Comments
 (0)