On 01/26/2011 03:17 PM, Jochen Theodorou wrote:
Am 26.01.2011 15:04, schrieb Rémi Forax:
[...]
It's optimized for 64bits.
But if you enable invokedynamic, you disable escape analysis*.
For small benchmarks with a dynamic language, it severely impact
performance.
* there is a partial fix in hotspot repository that enables escape
analysis when
invokedynamic is used. But EA analysis in not yet able to look through
invokedynamic.
I am not sure I would call that optimized if an essential feature for
accelerating the code is not available anymore. True, it is one of
those stupid microbenchmark examples and inlining isn't going to help
at all for the fibonacci problem but I had at least expected it to be
as fast as reflection.
Could you send your code ?
With my tests, it's faster than reflection.
Does this mean the jvm can do escape analysis through reflection, but
not through invokedynamic?
It's just not yet implemented for invokedynamic, but it will be.
Don't forget that jdk7 is still a beta and thus contains rough edges.
For reflection, after 60 invocations, reflection generate a bytecode stub,
reflection is not that slow. Also recently, a security token cache was
implemented to
avoid to do the same security check again and again.
It's a cache so if you use reflection everywhere, you will have a lot of
cache miss
that doesn't appear your micro-benchmark.
Then it would be really nice, for it becoming a really useful feature,
to have that part fixed.
Is there any example of a benchmark that shows that invokedynamic on
b125 is faster then reflection?
bye Jochen
Rémi
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
