• 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 ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Paul Clapham
  • Devaka Cooray
  • Ron McLeod
  • paul wheaton
Saloon Keepers:
  • Tim Moores
  • Piet Souris
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Al Hobbs
  • Frits Walraven
  • Scott Selikoff

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
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
A lot of people cry when they cut onions. The trick is not to form an emotional bond. This tiny ad told me:
the value of filler advertising in 2021
    Bookmark Topic Watch Topic
  • New Topic