On Tue, 9 Jun 2026 08:35:41 GMT, Ivan Bereziuk <[email protected]> wrote:
>> test/hotspot/jtreg/runtime/NMT/MallocLimitTest.java line 118:
>>
>>> 116: output.shouldNotHaveExitValue(0);
>>> 117: output.shouldMatch("\\[nmt *\\] MallocLimit: total limit:
>>> 1024K \\(oom\\)");
>>> 118: output.shouldMatch("\\[warning\\]\\[nmt *\\] MallocLimit:
>>> reached global limit \\(triggering allocation size: \\d+[BKM], allocated so
>>> far: \\d+[BKM], limit: 1024K\\)");
>>
>> I would not touch these leading `.*` as they make the test still usable if
>> the person running the test selects different log decorators. Arguably all
>> log checks could benefit from this, though in practice the need has not
>> arisen, but that doesn't mean we should remove them where they are present
>> IMO.
>
> `OutputAnalyzer::shouldMatch()` makes a "global" regexp search anywhere in
> stdout/stderr.
> And the removal of the leading ".*" does not make the search any more
> restrictive.
>
> And even in "line-by-line" variant `OutputAnalyzer::shouldMatchByLine()`, the
> removal of leading `.*` should have no effect. It would matter for
> `shouldMatchByLine()` only if the pattern itself uses anchors or groups in a
> way where consuming the prefix changes the match, for example `^.*\[warning\
> ]...`. A plain leading `.*` without an unanchored token still will not add
> decorator tolerance.
>
> @dholmes-ora please correct if I have misunderstood the point.
I was assuming these were implicitly matched from start-of-line. If that's not
the case then they are redundant as you note.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31338#discussion_r3385042837
