FULL PRODUCT VERSION :
java version "1.7.0_60"
Java(TM) SE Runtime Environment (build 1.7.0_60-b19)
Java HotSpot(TM) 64-Bit Server VM (build 24.60-b09, mixed mode)

FULL OS VERSION :
Linux 2.6.32-358.11.1.el6.x86_64 #1 SMP Wed May 15 10:48:38 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux


A DESCRIPTION OF THE PROBLEM :
Escape analysis no longer detects that a boxed integer being passed to HashMap#get can be stack allocated. This is used within the NIO select implementation, therefore increasing latency in network receives.

THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Yes

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

REGRESSION. Last worked in version 7u21

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Executing the Test class below with the following arguments:

java -ea -server -Xms100m -Xmx100m -XX:+PrintGCDetails -verbose:gc -XX:+DoEscapeAnalysis Test

EXPECTED VERSUS ACTUAL BEHAVIOR :
Under 1.7.0_21 no garbage collection occurs. With 1.7.0_60 many young gen GCs occur.
REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.HashMap;

public class Test {
    public static void main(String[] args) {
        HashMap<Integer, String> m = new HashMap<Integer, String>();

        for (int i=0;i<100000;i++) {
            if (check(m)) {
                System.out.println("True");
            }
        }
    }

    private static boolean check(HashMap<Integer, String> m) {
        boolean check = false;
        for(int i = 0; i < 1000; i++) {
            check |= m.get(new Integer(i)) != null;
        }
        return check;
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
This case occurs within NIO select. Without escape analysis, workarounds are:

- Revert to using standard IO rather than NIO.
- Override the bootclasspath with a reimplementation of NIO selectors that are garbage free.