• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Java performence

 
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Why do we need XX:CompileThreshold and what is the advantage of it
Thanks
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic