JDK-8225239 : Refactor NetworkInterface lookups
- Type: Enhancement
- Component: core-libs
- Sub-Component: java.net
- Affected Version: 8u212,11,13
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2019-06-04
- Updated: 2021-10-20
- Resolved: 2019-07-05
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 14 |
|---|
14 b05Fixed  |
Related Reports
|
Relates :
|
|
|
Relates :
|
Description
JDK-8223214 changed logic around to cause a slight increase in classes loaded when calling InetAddress.getLoopbackAddress(), which can be linked to a tiny footprint increase in 13-b22 since these classes end up in the default CDS archive. We can recuperate slightly by arranging so that we don't load Inet4AddressImpl unnecessarily from Inet4AddressImpl etc. A related inefficiency is that the call to NetworkInterface.getByInetAddress is inefficient since it enumerates and loops over all IPv4 and IPv6 interfaces, regardless of the type of address we're looking up. This is pre-existing, but JDK-8223214 puts it up there. How costly this superfluous enumeration is depends on the system you're on and it's network configuration, but I get a small improvement (~0.1ms) on startup from a patch that only searches the relevant interfaces.
Comments
|