hg: hsx/hotspot-comp/hotspot: 7013347: allow crypto functions to be called inline to enhance performance

[John Rose]

On Feb 7, 2012, at 6:05 PM, Krystal Mok wrote:

> Yes, I've read that blog post in the link before. We'll make sure we investigate thoroughly and post empirical test results the next time we post performance-related patches.
> 
> Thanks for reminding that :-)

Sure!

> There's a related question that I'm looking for advice. We've seen some of our Java apps having to call native code extensively, through JNI. The team that developed the library in native code doesn't have the resource to re-write the whole thing to a Java version, so the clients from Java side are stuck with JNI. That's not really "typical workload", but it's happening on our production site. Running standard benchmarks like SPECjvm or SPECjbb wouldn't exercise JNI invocations that frequently, so perf improvements in the JNI wrappers won't show up significantly in these benchmarks.
> 
> How should we benchmark for situations like this? Should we run the standard benchmarks to show that performance doesn't degrade on typical workloads, and that it improves in a special case?

Yes, that's the right approach.  You need a proof, experimental and/or deductive, that your change won't hurt the standard benchmarks.

-- John