Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

JIT(JUST IN TIME) COMPILERS  RSS feed

 
Anand Divakaran
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i was reading the java buzzwords when i came across the buzzword HIGH PERFORMANCE, it spoke on jit compilers .

what are JIT Compilers and how do they improve the performance in the context of java?
 
Henry Wong
author
Sheriff
Posts: 22832
119
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When a class file is loaded into a JVM, it is initially interpreted. While that is happening, the JIT will compile the class files into the native code for the local processor. At a certain point, the execution will cut over to the native compiled code instead of interpreted code.

Furthermore, the JVM will keep track of hotspots in the code (during this execution). From this, it will recompile certain codes, with specific optimization based on what it has found. Again, at a certain point, the execution will cut over to this newly optimized code.

Henry
 
Doug Slattery
Ranch Hand
Posts: 294
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys,

I'm primarily hanging out in the SCJP forum, but this reply of mine didn't get a response, so I'll repost it in this thread where it seems more appropriate...
-----------------------------

Hi guys,

This thread is perfect for an opinionated point of view of mine, a bit OT (off topic) from the exam...

My former employer has been developing web sites for some time now. At the beginning (of web development), they hired a few web developers that had experience in Java. After deploying some sites, there were complaints that they were slow. Eventually, they were rewritten in 'C'. Several years later, they are back in the same boat. Recently, a couple other rather large sites were deployed in Java and they are experiencing the same "slow" complaints. The proposed solution was to add faster servers. To me, that's kind of stupid because the systems are scalable and that solution is only short term as the root problem will scale exponentially.

I'm not knocking JIT, as it has a well suited place such as a daemon or service where it will be running for long periods of time and the JIT overhead will be minimal.

But to use Java as a cgi on a high traffic web server?.?. That doesn't sit right with me. IMHO, a lower level language such as 'C' is better suited for web servers, and even the JNI mentions that one of its purposes is where performance counts and Java falls short in that area.

I also wonder why they decided to use JIT, and not create a standalone executable?.?. Couldn't the JVM check for it at runtime and compile one if it doesn't exist?

I'm looking forward to hearing the responses of the gurus .

Aloha,
Doug
 
Nicholas Jordan
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Doug Slattery:]   I'll repost it in this thread where it seems more appropriate...

Probably should start a new thread, post new topic.

[Doug Slattery:]   After deploying some sites, there were complaints that they were slow.

define slow - along with server load generalizations and some picture of what is meant by slow.

[Doug Slattery:]   But to use Java as a cgi on a high traffic web server?.?.

cgi invokes a new process for each request - java's approach to Threading begs the world to run it on true mp - this requires hardware and compiler to make some realistic use of Thread dispatching on mp bus architecture - which is not fully documented in the coder's library. A true parallelizing implementation of Java on a true MP hardware base would collapse runtimes to vanishing response times.

[Doug Slattery:]   The proposed solution was to add faster servers. To me, that's kind of stupid because the systems are scalable and that solution is only short term as the root problem will scale exponentially.

See Books by Dov Bulka
  • Java Performance and Scalability - 2000
  • Efficient C++ : Performance Programming Techniques - 1999 - 332

  • Then let's continue this discussion.

    [Doug Slattery:]   I'm not knocking JIT, as it has a well suited place such as a daemon or service where it will be running for long periods of time and the JIT overhead will be minimal.

    Consider this evaluation as contra-distinct to your opening position.

    [Doug Slattery:]   I also wonder why they decided to use JIT, and not create a standalone executable?.?. Couldn't the JVM check for it at runtime and compile one if it doesn't exist?.

    How many times have you tried to sell equipment ? Java is remarkably powerful, but looks to me like a testbed that can be re-compiled into faster object code. It's really a design decision, look at some of the beginner work we see at javaranch, would you want that running in kernel, ring-0 services ? Think about your question, we will be moved by the Moderator .... maybe you can have some productive speculation by then.

    http://www.docdubya.com/belvedere/cpp/question.htm

    [ September 29, 2007: Message edited by: Nicholas Jordan ]
     
    Doug Slattery
    Ranch Hand
    Posts: 294
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Nicholas & thanks for the reply.
    To clarify...

    Originally posted by Nicholas Jordan:
    [Doug Slattery:]   I'll repost it in this thread where it seems more appropriate...

    Probably should start a new thread, post new topic.

    I was using the Search First etiquette from the FAQ to not hijack this thread.

    I'll start a new thread if this one hasn't been moved after I finish replying.

    [Doug Slattery:]   After deploying some sites, there were complaints that they were slow.

    define slow - along with server load generalizations and some picture of what is meant by slow.

    As this information is from my former employer, I no longer have access to it. However, after rewriting the cgi's in 'C', performance did noticeably improve under the same and heavier loads as the number of users accessing the site increased over time. I should also mention the server is Linux based (RedHat ES3) quad processor system using Apache with 16GB ram.

    [Doug Slattery:]   But to use Java as a cgi on a high traffic web server?.?.

    cgi invokes a new process for each request - java's approach to Threading begs the world to run it on true mp - this requires hardware and compiler to make some realistic use of Thread dispatching on mp bus architecture - which is not fully documented in the coder's library. A true parallelizing implementation of Java on a true MP hardware base would collapse runtimes to vanishing response times.


    Understood, but for my situation, afaik threading isn't necessary. Every request is first authenticated against session information stored on the server that gets created when a user logs in. There's a split at this point depending if the authentication is good or not. Assuming it's good, more than likely access to the database would happen. When that comes back, an html generator would dynamically create the response page with the results of the query. Pretty basic stuff.

    Could one of the possible causes of the reported slowness be contributed to the overhead of JIT? Another possibility I'm unsure of is doesn't the JVM have to run before the Java program, thus adding more overhead? Could the problem also be inherent in the Java language itself?

    [Doug Slattery:]   The proposed solution was to add faster servers. To me, that's kind of stupid because the systems are scalable and that solution is only short term as the root problem will scale exponentially.

    See Books by Dov Bulka
  • Java Performance and Scalability - 2000
  • Efficient C++ : Performance Programming Techniques - 1999 - 332

  • Then let's continue this discussion.

    I understand about writing efficient programs. That and security are to of my top pet peeves. I've done lots of reading on optimizing code and optimizing compilers (in 'C' that is). I'm still a little green when it comes to Java, which is why I'm asking these questions .

    [Doug Slattery:]   I'm not knocking JIT, as it has a well suited place such as a daemon or service where it will be running for long periods of time and the JIT overhead will be minimal.

    Consider this evaluation as contra-distinct to your opening position.

    I'll respectfully disagree and elaborate a bit more that my opinion is based on using Java for cgi programs on a high traffic web server considering JIT adds overhead (and maybe other things as well) as opposed to a stand alone executable.

    [Doug Slattery:]   I also wonder why they decided to use JIT, and not create a standalone executable?.?. Couldn't the JVM check for it at runtime and compile one if it doesn't exist?.

    How many times have you tried to sell equipment ?

    I was self employed for 8 years and have moved a lot of iron my friend.

    Java is remarkably powerful, but looks to me like a testbed that can be re-compiled into faster object code.

    I'll agree with you there. I do find it more convenient to use over 'C' in a lot of cases (device drivers excluded) .

    It's really a design decision,

    Ok

    look at some of the beginner work we see at javaranch, would you want that running in kernel, ring-0 services ?


    Although, I doubt that Java can run in a "true" kernel (operating system that is) as it stands today.

    Think about your question, we will be moved by the Moderator .... maybe you can have some productive speculation by then.

    http://www.docdubya.com/belvedere/cpp/question.htm


    [ September 29, 2007: Message edited by: Nicholas Jordan ]


    Aloha,
    Doug
     
    Henry Wong
    author
    Sheriff
    Posts: 22832
    119
    C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Understood, but for my situation, afaik threading isn't necessary. Every request is first authenticated against session information stored on the server that gets created when a user logs in. There's a split at this point depending if the authentication is good or not. Assuming it's good, more than likely access to the database would happen. When that comes back, an html generator would dynamically create the response page with the results of the query. Pretty basic stuff.

    Could one of the possible causes of the reported slowness be contributed to the overhead of JIT? Another possibility I'm unsure of is doesn't the JVM have to run before the Java program, thus adding more overhead? Could the problem also be inherent in the Java language itself?


    If you are going to use Java on a web server, don't use it as part of a CGI script. Java on a web server is either done with Servlets or JSPs.

    The starting of the JVM, and the JIT itself will slow a program down. With CGI scripts, they have to be started everytime. With Servlets (and JSPs), the JVM is started with the first call. In every subsequent call, it will use the same instance.

    And since JITs actually detect hotspots, and re-optimize with many calls -- a servlet that has been running a while, can actually be faster than C in many cases.

    Henry
     
    Pat Farrell
    Rancher
    Posts: 4678
    7
    Linux Mac OS X VI Editor
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    No CGI, use servlets and a good servlet engine. There are many good ones, decent ones open source like Tomcat.

    Picking a server config is non-trivial if you want serious performance. Many folks start with Apache and dispatch to Tomcat for servlets. But sometimes you are better off with Tomcat as the whole thing. It depends on the mix, if most of your load is sevlets and JSPs, Apache is not bringing much to the table.

    There are many serlet engines, I've had good experiences with Caucho's Resin.

    Glassfish is gaining traction.

    In most real applications with real volume, the bottlenecks are talking to the database, not the performance of the application domain code. The language choice is not that important. And the JIT systems can deliver very impressive performance.

    The days of an average C programmer being able to write faster executing code in C over the average programmer in a JIT language are over. Many optimizations are too complex for humans, compilers and the runtime systems can do a better job, they can instrument the code and fix what is really slow, not just what the programmer thinks is slow.
     
    Doug Slattery
    Ranch Hand
    Posts: 294
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks for the replies Henry & Pat.

    They were pretty informative to me.

    Aloha,
    Doug
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!