JDK-8193128 : Reduce number of implementation classes returned by List/Set/Map.of()
- Type: Bug
- Component: core-libs
- Sub-Component: java.util:collections
- Priority: P3
- Status: Resolved
- Resolution: Fixed
- Submitted: 2017-12-06
- Updated: 2018-05-15
- Resolved: 2018-03-22
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 11 |
|---|
11 b07Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
The static List, Set and Map factories added in 9 strike a balance between reducing footprint (by providing specialized implementations for small number of entries) and speed (using @Stable guarantees enables a JIT to constant fold). However, the number of implementation classes can have negative effects: - Callsites may become bi- or megamorphic that would be monomorphic if it only observed a single implementation, e.g., ArrayList. - Although trivially JITed, splitting work over 4 List implementation delays how quicky individual implementations reach optimal compilation levels, which can affect startup and warmup (observed after JDK-8184777) As such, this is part Enhancement, part Bug (observable regressions when using List.of() compared to arrays or ArrayList) Experiments show we can profitably reduce the number of implementation classes to 2 while remaining footprint neutral. We could also provide an option to only have one implementation, forfeiting the footprint gain to ensure monomorphic callsites.
Comments
|