2

For the below given code , I see lot of GC activity. As per my understanding this is a suitable scenario for EA. Why EA is not effective. DummyObject has nothing allocated inside it. JVM options used : -server , -verbosegc.

   static void anayzeEA()
{
    for(int i = 0 ; i < 100000000; i++) {
        DummyObject obj = new DummyObject();
        if(obj.hashCode() == 97787) { //to prevent the obj being optimized            
         System.out.println(obj.hashCode());
        }
    }

}
Pavan Manjunath
  • 27,404
  • 12
  • 99
  • 125
Shilu
  • 81
  • 2
  • It is not about how fast the code should run. Why should GC run frequently to collect memory and that is very obvious with the flag -verbosegc – Shilu Jun 28 '12 at 06:30

3 Answers3

1

See related Q&A here which suggests you can download a debug JDK and use command line options: -XX:+UnlockDiagnosticVMOptions -XX:+PrintEscapeAnalysis -XX:+PrintEliminateAllocations

to print out the escape analysis events as they happen.

Community
  • 1
  • 1
Nitsan Wakart
  • 2,841
  • 22
  • 27
0

Some observations

It seems like the obj.hashCode() is a native call and the object may escape . Changing obj.hashCode() to obj.getMyCode() (a method which returns the System.currentTimeMillis()% staticObjCount) made it work . No GC activity observed. However following method never got escape analysis in effect with all the suggestions mentioned
here

 public static long test1() 
{
    long r = 0;
    byte[] arr = new byte[(int)System.currentTimeMillis() % 1024]; 
    if(arr.length == 998 ) {
        ++r;
    }
    return r;
}

JVM options used -server -verbosegc -XX:CompileThreshold=1

Test1 is called over a number of times . Same old story. Java allocates memory in heap, GC comes and makes everything slow. was too excited about this feature.

Community
  • 1
  • 1
Shilu
  • 81
  • 2
0

Java API says:

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)

So you are generating objects, producing non-predictable hashCodes for each and compare them to some value. Additional it's a native method, so the JIT doesn't know what's happening inside.

Escape Analysis may be good, but there's currently no support for crystal balls. ;-) Try overriding it with your own method, returning 12345.

Hardcoded
  • 6,476
  • 2
  • 22
  • 20
  • This answer is incorrect. The documentation clearly says that hashCode should be different as much as possible, but it is not required to do it at all. For example, even `return 0;` is a legal `hashCode()` implementation. Thus, "non-predictable hashCodes" is not a reason for preventing a memory allocation optimization. – Nayuki Jan 12 '16 at 05:07
  • @NayukiMinase The hashCode-Method of java.lang.Object is a native method, so it's running outside of the JVM and can't be optimized by the JVM. All I said is, overwrite the hashCode method and return your own value, so that you get an optimizable hashCode-Method. – Hardcoded Jan 15 '16 at 09:33