The GTest LogSelectionList.combination_limit tests whether LogSelectionList::MaxSelections > LogTagSet::ntagsets()
In current OpenJDK head, the number of tagsets is running close to the defined value of LogSelectionList::MaxSelections. In our downstream build of SapMachine where we add one additional tagset, this test breaks.
Looking more closely at the test, it seems a bit dubious to have this check. Should the MaxSelections value be incremented by a few digits to cater for future growth? Is the number of actual tagsets really the thing that we should test for here as upper bounds?
Also, it seems in gtests the tagset number is higher than in a JDK.
In current OpenJDK head, the number of tagsets is running close to the defined value of LogSelectionList::MaxSelections. In our downstream build of SapMachine where we add one additional tagset, this test breaks.
Looking more closely at the test, it seems a bit dubious to have this check. Should the MaxSelections value be incremented by a few digits to cater for future growth? Is the number of actual tagsets really the thing that we should test for here as upper bounds?
Also, it seems in gtests the tagset number is higher than in a JDK.
- duplicates
-
JDK-8327098 GTest needs larger combination limit
-
- Resolved
-
-
JDK-8325490 gtest LogSelectionList::combination_limit Running out of LogTagSet
-
- Closed
-