• Post Reply Bookmark Topic Watch Topic
  • New Topic

Java performence  RSS feed

 
Vijay Kumar
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why do we need XX:CompileThreshold and what is the advantage of it
Thanks
 
Tony Morris
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Last I looked, it was a threshold of method invocations before a method is inlined by JIT/HotSpot.

It is also a useful refutation to the usual (but erroneous) claim that manual inlining is a performance enhancement (if anything, it is a degradation). It is also related to the fact that Java cannot prove that its functions are pure (Java has functions, but they are disguised i.e. OO can be transformed into functional).

For example (a typical one), a lot of people will write code like this:

...believing it is a performance enhancement as opposed to

Since Java has only an English-stated specification that Collection.size() is a pure function (is referentially transparent), developers might not trust the implementation of that specification, and so perform a manual inline. Others might argue that it is more readable (which is subjective and I disagree that it is more readable); some think it is a performance enhancement - which it clearly (I hope) isn't.

In a pure functional language, Collection.size() (its analogous to be precise) is guaranteed to return the same value from now until the end of the universe/time (read: while computational progression exists) by the compiler/language, therefore, the fear of inadvertant specification failure goes away. Nevertheless, you need to trust that a specification implementation adheres to its contract anyway - even given the substandard tools - otherwise, you run into huge problems and specifically, laborious techniques.

It's all fun to watch at least
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!