Performance improvement by fixing hashCode()

[testn]

Perform minimal change to hashCode() to reduce hash collision. Similar attempt to the fix in #775 to address #772 but much simpler.

[juherr]

As I said on #772:

I never feel good perf improvments without something concrete to evaluate it.

[testn]

Yes the performance improves. I just didn't have to patience to run the full test in #772. It cuts at least a couple seconds from the test that takes around 1-2 minutes to run over maven.

[vlsi]

BaseTestMethod#equals uses identity comparison like getInstance() == other.getInstance(), so the hashCode implementation should use identity hashCode rather than user-provided implementation.

In other words, this should be System.identityHashCode(m_instance)

Other than that, the change is a clear improvement with little-to-no risk, so it is safe to merge if m_instance.hashCode() is replaced with identityHashCode

[cbeust]

I'm confused. How is this a performance improvement? It does more work than the previous implementation.

[vlsi]

Extra work is negligible, and the new implementation produces better hash codes, so there are less chances for collision in

   at java.util.HashSet.add
   at org.testng.internal.DynamicGraph.setStatus 
   at org.testng.internal.thread.graph.GraphThreadPoolExecutor.setStatus

[juherr]

@vlsi Any idea how to measure the improvement "easily"?

[vlsi]

Is there a real need to measure this change?

It might be fun to add "reduce overheads by 10x when running dataprovider test with 100000 values with 16 threads", however, I would rather work on DI improvements.

Of course it would be nice to have a performance regresssion suite, however, it is not the most important issue at the moment.