-
Enhancement
-
Resolution: Duplicate
-
P4
-
None
The gtest `LogSelectionList::combination_limit` asserts that
`LogTagSet::ntagsets() < LogSelectionList::MaxSelections`.
On at least linux-x64-debug this is triggered if a single new LogTagSet is added.
The normal `linux-x64-debug` java binary uses 244 LogTagSets, the gtestLauncher adds an additional 11 LogTagSets brining the total to 255 which is just on the limit.
This test was added inJDK-8153731 when the MaxSelections was bumped to 256. It is unclear if limiting the LogTagSet number by the available LogTagSelections is correct.
It does at least warrant some investigation. Should the test be removed or is there some technical reason for limiting the used LogTagSets to the number of LogTagSelections?
The following are exclusively used by the gtest;
```
gc+class
gc+safepoint+logging
logging+class
logging+gc
logging+gc+class
logging+gc+class+safepoint+heap
logging+safepoint
logging+safepoint+jni
logging+test
safepoint+class
test
```
`LogTagSet::ntagsets() < LogSelectionList::MaxSelections`.
On at least linux-x64-debug this is triggered if a single new LogTagSet is added.
The normal `linux-x64-debug` java binary uses 244 LogTagSets, the gtestLauncher adds an additional 11 LogTagSets brining the total to 255 which is just on the limit.
This test was added in
It does at least warrant some investigation. Should the test be removed or is there some technical reason for limiting the used LogTagSets to the number of LogTagSelections?
The following are exclusively used by the gtest;
```
gc+class
gc+safepoint+logging
logging+class
logging+gc
logging+gc+class
logging+gc+class+safepoint+heap
logging+safepoint
logging+safepoint+jni
logging+test
safepoint+class
test
```
- duplicates
-
JDK-8327098 GTest needs larger combination limit
- Resolved
-
JDK-8325508 Potential issue in GTest LogSelectionList.combination_limit
- Closed