Bug ID: JDK-7039343 Performance Downgrade:NetworkInterface.getNetworkInterface() takes 100x longer in JDK 7

Versions (Unresolved/Resolved/Fixed)

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.

JDK 8
8Resolved

J2SE Version (please include all output from java -version flag):

java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b139)
Java HotSpot(TM) Client VM (build 21.0-b09, mixed mode, sharing)

Does this problem occur on J2SE 1.4.x, 1.5 or 6?  Yes / No (pick one)
No


Operating System Configuration Information (be specific):
Windows Vista Business SP2

Hardware Configuration Information (be specific):
HP Pavillion dv9000
Windows Vista Business SP2 32 bit
3 GB RAM
Intel Core 2 Duo T9300



Bug Description:

Call to java.net.NetworkInterface.getNetworkInterfaces() takes around 100 times longer in Java 7

Had never tried this call with Java 7 before and do not know when this first 
started occuring.  

Have
 often wondered why this machine comes up with over 800 interfaces...
obviously most of them are not
 real.  They come up with toString values 
like "name:net751 (6TO4 Adapter) index: 767 addresses:".

Ever since first tried this call (years ago) this laptop has always 
given a huge amount of interfaces;
 odd!!

Steps to Reproduce (be specific):

Run attached test program

Using Test6 run configuration
-----------------------------
Property 1: 1.6.0_24
Property 2: 1.6.0_24-b07
Property 3: Windows Vista
Property 4: x86
Property 5: 6.0
Property 5: Service Pack 2
Getting interfaces 13:24:57
Got interfaces 13:24:58
Found 811 interfaces 13:24:58
Done 13:24:58
Elased time: 0.778

Using Test7 run configuration
-----------------------------
Property 1: 1.7.0-ea
Property 2: 1.7.0-ea-b139
Property 3: Windows Vista
Property 4: x86
Property 5: 6.0
Property 5: Service Pack 2
Getting interfaces 13:25:18
Got interfaces 13:26:47
Found 811 interfaces 13:26:47
Done 13:26:47
Elased time: 89.285

EVALUATION Looking at the output of simple java program, run on the customers system, to retrieve the network interfaces, it can be seen that there are hundreds of "Microsoft 6to4 Adapter"s. The output of 'ifconfig /all' is not showing all these interfaces. Doing a quick search on the net this would appear to be a known Windows issue. Quite a few people are complaining about this, and there are many instructions on how to remove them. It possible to view the interfaces in the device manager. Instructions: Start �� Run �� Type devmgmt.msc ��and click OK �� in Device Manager, click View and select Show hidden devices �� expend Network Adapters �� check the status/number of 6TO4 adapters. Closing this bug as this would appear to be a Windows platform issue.

18-05-2011

EVALUATION Having such a large number of interfaces seems very odd, and certainly not a standard setup. The customer has run some tests with -Djava.net.preferIPv4Stack=true and sees the same slow behavior with JDK6. This leads me to believe that this problem appears in JDK7 (with and without -Djava.net.preferIPv4Stack=true) because of a correctness fix, CR 6707289. The Windows native code has two separate code paths for retrieving interfaces, both use different Win32 API's. These code paths exists to support older Windows platforms (pre Windows XP). CR 6707289 changed the XP (or greater) code path to use enumAddresses_win to determine the IPv4 addresses, because of an issue with the getAddrsFromAdapter Win32 API. See CR 6707289 for more details. It is most likely that this change has caused the performance issue the customer is seeing. More investigation needs to be done to determine why we are reporting so many interfaces, when the output of 'ipconfig /all' does not show these.

18-05-2011