Page 2 of 3 FirstFirst 123 LastLast
Results 21 to 40 of 44
  1. #21
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,335
    Blog Entries
    7
    Rep Power
    20

    Default

    Quote Originally Posted by couling View Post
    I find that very hard to believe.
    Start reading here. Those JIT compiled parts can be recompiled (and over again if needed) to optimize even better given statistics from the already running code. Classic compilers can never do that.

    kind regards,

    Jos
    cenosillicaphobia: the fear for an empty beer glass

  2. #22
    Tolls is online now Moderator
    Join Date
    Apr 2009
    Posts
    11,792
    Rep Power
    19

    Default

    Quote Originally Posted by couling View Post
    I would be more inclined to believe that efficiency benafits of java are more to do with the specifics of the language itself and the way that programmers use it.
    There's a Java adage...write dumb code. That is, don't try to second guess the JVM because that often results in complex code that actually hinders the JIT from doing its job of creating efficient compiled code. So the way most programmers use it, especially those trying to optimise their code without actually profiling it, doesn't result in efficiency benefits.

    The article is also a fairly good description of what Jos is getting at.

  3. #23
    couling is offline Member
    Join Date
    Nov 2010
    Posts
    54
    Rep Power
    0

    Default

    Quote Originally Posted by JosAH View Post
    Start reading here. Those JIT compiled parts can be recompiled (and over again if needed) to optimize even better given statistics from the already running code. Classic compilers can never do that.

    kind regards,

    Jos
    That's an interesting concept, but the link doesn't appear to support your claim (I'd be very interested in reading one that does as the idea is cool*). Optomising over and over won't continually speed up your program just as zipping an already zipped file will very quickly not make the file any smaller. HotSpot is only there to choose which bits to optomise. A classic compiler doesn't mind taking an hour an WILL optomise the whole program whereas Java can't make the end user wait an hour so uses HotSpot to figure out which bits need the optomisation the most.

    The optomisations this page mentiones are language specific, not specific to the use of byte code or JIT. That was pretty much the point I was making.




    *I'm specifically interested about how you could optomise a program in this way without the overhead that comes with fine-grained monitoring simular to that used with debugging.
    ----Signature ----
    Please use [CODE] tags and indent correctly. It really helps when reading your code.

  4. #24
    couling is offline Member
    Join Date
    Nov 2010
    Posts
    54
    Rep Power
    0

    Default

    Quote Originally Posted by Tolls View Post
    There's a Java adage...write dumb code.
    Err, thats what I meant by the the way that programmers use it, I didn't know there was another way with java ;) . Still thanks for the link. I'll spend some time reading that tonight.
    ----Signature ----
    Please use [CODE] tags and indent correctly. It really helps when reading your code.

  5. #25
    Tolls is online now Moderator
    Join Date
    Apr 2009
    Posts
    11,792
    Rep Power
    19

    Default

    You'd be surprised the hoops some people jump through trying to "optimise" their code.

  6. #26
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,335
    Blog Entries
    7
    Rep Power
    20

    Default

    Quote Originally Posted by couling View Post
    That's an interesting concept, but the link doesn't appear to support your claim (I'd be very interested in reading one that does as the idea is cool*).
    Then you haven't read the link I supplied very carefully. e.g. Vectors are synchronized except when the JIT/Hotspot mechanism can prove that a Vector is only used locally; it removes all calls to the lock/unlock OS calls. It even does that when a Vector is passed to another method; if it also uses that Vector locally the same locking can be removed. Suppose we're talking about methods A and B (and A calls B with that Vector). Also assume B contains a computing intensive loop; the JIT compiler has most likely compiled it long before A is compiled by the JIT and also long before the methods of the Vector class are compiled by the JIT; they are compiled again if the Hotspot mechanism detects that this Vector is only used locally.

    kind regards,

    Jos
    cenosillicaphobia: the fear for an empty beer glass

  7. #27
    docesam is offline Member
    Join Date
    Apr 2009
    Posts
    5
    Rep Power
    0

    Default

    ok ,now at the end after all the optimization and JIT compiler use that the JVM does : is java faster or at least as fast as a compiled language like c++ ?

  8. #28
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,335
    Blog Entries
    7
    Rep Power
    20

    Default

    Quote Originally Posted by docesam View Post
    ok ,now at the end after all the optimization and JIT compiler use that the JVM does : is java faster or at least as fast as a compiled language like c++ ?
    Yes, it can even be faster than C++ unless C++ is compiled by a JIT/Hotspot mechanism in a similar way.

    kind regards,

    Jos
    cenosillicaphobia: the fear for an empty beer glass

  9. #29
    docesam is offline Member
    Join Date
    Apr 2009
    Posts
    5
    Rep Power
    0

    Default

    Quote Originally Posted by JosAH View Post
    Yes, it can even be faster than C++ unless C++ is compiled by a JIT/Hotspot mechanism in a similar way.

    kind regards,

    Jos
    thank you for taking the time and effort to reply.

    is there any benchmarks / research to back up that ?

  10. #30
    couling is offline Member
    Join Date
    Nov 2010
    Posts
    54
    Rep Power
    0

    Default

    Quote Originally Posted by JosAH View Post
    Then you haven't read the link I supplied very carefully. e.g. Vectors are synchronized except when the JIT/Hotspot mechanism can prove that a Vector is only used locally; it removes all calls to the lock/unlock OS calls. It even does that when a Vector is passed to another method; if it also uses that Vector locally the same locking can be removed. Suppose we're talking about methods A and B (and A calls B with that Vector). Also assume B contains a computing intensive loop; the JIT compiler has most likely compiled it long before A is compiled by the JIT and also long before the methods of the Vector class are compiled by the JIT; they are compiled again if the Hotspot mechanism detects that this Vector is only used locally.

    kind regards,

    Jos
    You seem to be referencing Escape analysis and lock coarsening

    HotSpot will not continually see-saw between having the lock and not having it. If it's required then JIT can not optomise it out. If it's never required then what's to stop a classic compiler (which optomises the whole program) from spotting the same thing?

    This is a cool feature of the way java handles locks, but not its use of byte code.



    Actually after reading more on the subject I will conceed that JIT has one party trick up its sleave that is not open to classic compilers. This only kicks in when programs load classes dynamically... explained here under "Dynamic Deoptimization".

    If classes are to be dynamically loaded then a classic compiler will have no idea about what those classes will do. It must limit its optomisations accordingly.

    JIT doesn't need to. It simply makes the optomisations regardless of the later consiquences. If a dynamically loaded class is later found to break its compiled code, it simply re-compiles to remove the optomisations.
    Last edited by couling; 11-24-2010 at 12:49 AM.
    ----Signature ----
    Please use [CODE] tags and indent correctly. It really helps when reading your code.

  11. #31
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,335
    Blog Entries
    7
    Rep Power
    20

    Default

    Quote Originally Posted by couling View Post
    You seem to be referencing Escape analysis and lock coarsening

    HotSpot will not continually see-saw between having the lock and not having it.
    Of course not: in my example if there's no indication in A nor B, nothing will be recompiled; if in B it is detected that that particular Vector is only used locally then A can be recompiled (i.e. the locks can be removed).

    kind regards,

    Jos
    cenosillicaphobia: the fear for an empty beer glass

  12. #32
    couling is offline Member
    Join Date
    Nov 2010
    Posts
    54
    Rep Power
    0

    Default

    This is actually a very different optomisation and, as I stated before, totaly achievable in a classic compiler. A simple call graph will provide all the information needed.

    This optomisation is not performed based on when a class is only used locally but where object has only been used locally.

    Java Code:
    class MyClass {
        public static Vector mustLock;
    
        //...
    
        public void foo(object o) {
            Vector noLock = new Vector();
            noLock.add(o); // will not use the lock
            mustLock = noLock;
        }
    
        public void bar(object o) {
            mustLock.add(o); // will use the lock
        }
    }
    Re-compiling the code is of no use here as the Vector class is the same class for both mustLock and noLock. Even when talking about the same object, it depends on context as to wether the lock us used.

    My guess is that in order to do achieve this the new JVM JIT compiler has moved the locking mechanism into being part of the calling convention so that the task of locking the object is given to the calling function. That way the compiler can choose wether or not to use the lock on a call by call bases.

    Kind Regards
    Last edited by couling; 11-24-2010 at 09:21 AM.
    ----Signature ----
    Please use [CODE] tags and indent correctly. It really helps when reading your code.

  13. #33
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,335
    Blog Entries
    7
    Rep Power
    20

    Default

    Quote Originally Posted by couling View Post
    This is actually a very different optomisation and, as I stated before, totaly achievable in a classic compiler.
    No it is not because a 'classic' compiler won't recompile the code for the (equivalent) of the Vector class. (unless some highly implementation defined #pragma's can be used (in C or C++)).

    kind regards,

    Jos
    cenosillicaphobia: the fear for an empty beer glass

  14. #34
    couling is offline Member
    Join Date
    Nov 2010
    Posts
    54
    Rep Power
    0

    Default

    It doesn't have to re-compile and in fact, as I stated with the example, it won't help! A classic compiler using this locking mechanism would be expected to come with its own optomised std libraries based on the same locking mechanism.

    I'm trying very carefully to draw a line between what java does that could be implemented in a classic compiler and what it does that could not. Re-compiling the standard libraries is not common practise, true, but why is it impossible? Call graph's are trivial, I've personally implemented a system to extract one as a Uni project using a third party parser.
    Last edited by couling; 11-24-2010 at 11:10 AM. Reason: cleaned up gramma
    ----Signature ----
    Please use [CODE] tags and indent correctly. It really helps when reading your code.

  15. #35
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,335
    Blog Entries
    7
    Rep Power
    20

    Default

    Quote Originally Posted by couling View Post
    It doesn't have to re-compile, and in fact as I stated with the example won't help! A classic compiler using this locking mechanism would be expected to come with its own optomised std libraries based on the same locking mechanism.
    True, but your example is quite a different example: the noLock/mustLock Vector isn't solely used locally. I don't really know what the Hotspot mechanism would do here. The Hotspot/JIT mechanisms don't really care about code duplication (if that is a concern to you) and they don't need different optimized versions of the same library because the library is only there in the form of byte code (which can be recompiled if needed).

    Quote Originally Posted by couling View Post
    I'm trying very carefully to draw a line between what java does that could be implemented in a classic compiler and what it does that could not. Re-compiling the standard libraries is not common practise, true, but why is it impossible? Call graph's are trivial, I've personally implemented a system to extract one as a Uni project using a third party parser.
    I don't know if it is possible to anticipate on every different situation that begs for a different version of some code (ahead of time). In the example you'd need a locking version of the Vector methods as well as a non-locking version; do you also need an inlined version of all the code? I think the size of those libraries might explode due to all the possible alternatives.

    kind regards,

    Jos
    cenosillicaphobia: the fear for an empty beer glass

  16. #36
    couling is offline Member
    Join Date
    Nov 2010
    Posts
    54
    Rep Power
    0

    Default

    Quote Originally Posted by JosAH View Post
    I don't know if it is possible to anticipate on every different situation that begs for a different version of some code (ahead of time).
    The Halting Problem tells us we can't predict everything. But my origional point was to question how much more really becomes possible by running the program.

    There is a trade of to be made. "suck it and see" sounds good in pricipal but may not be a very good idea as it could add a big overhead on re-compiling while your program evolves into a stable state. Additionally monitoring a programs performance actually slows it down. Just like Uncertainty Principle you can not know both a program's speed and where it is at the same time. The more precisely you monitor its position in code the slower it runs.

    This is why I'm so interested in what optomisations Java does based on hotspot statistics.

    Quote Originally Posted by JosAH View Post
    In the example you'd need a locking version of the Vector methods as well as a non-locking version
    No if the locking mechanism is moved to the calling function you really don't. Escape analysis us a standard part of compilers but the Java languge does make it much more effective.

    Quote Originally Posted by JosAH View Post
    and they don't need different optimized versions
    Different optomised version would leave open some very cool optomisations, but alas I've seen no reference to Java doing this. I wonder if they have some reason for not doing.
    ----Signature ----
    Please use [CODE] tags and indent correctly. It really helps when reading your code.

  17. #37
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,335
    Blog Entries
    7
    Rep Power
    20

    Default

    Quote Originally Posted by couling View Post
    The Halting Problem tells us we can't predict everything. But my origional point was to question how much more really becomes possible by running the program.
    True, but even trying to predict a a few, or 'some' of the possibilities can increase the size of the library beyond proportions.

    Quote Originally Posted by couling View Post
    There is a trade of to be made. "suck it and see" sounds good in pricipal but may not be a very good idea as it could add a big overhead on re-compiling while your program evolves into a stable state. Additionally monitoring a programs performance actually slows it down. Just like Uncertainty Principle you can not know both a program's speed and where it is at the same time. The more precisely you monitor its position in code the slower it runs.

    This is why I'm so interested in what optomisations Java does based on hotspot statistics.
    Here's another article by Sun; it also doesn't mention a simple exhaustive list of what the Hotspot mechanism can do; to tell you the truth, I've never seen such a list; maybe Sun/Oracle want to keep it a secret ;-)

    Quote Originally Posted by couling View Post
    No if the locking mechanism is moved to the calling function you really don't. Escape analysis us a standard part of compilers but the Java languge does make it much more effective.
    But that assumes that the compiler can move the locking mechanism from within the code of the Vector class to the caller's method. I don't think classic compilers do that.

    kind regards,

    Jos
    cenosillicaphobia: the fear for an empty beer glass

  18. #38
    couling is offline Member
    Join Date
    Nov 2010
    Posts
    54
    Rep Power
    0

    Default

    Thanks for the link I'll read it tonight.

    No I don't know a language which does this. All the languages I know are unable to remove a lock because locking is not part of the core language. In other languages it is an external package. The optomiser does not know what the lock is for so must leave it in.

    In general though, a good compiler can move code around and even remove code as much as it likes internally as long as the end result can be mathmatically garunteed to be the same.
    ----Signature ----
    Please use [CODE] tags and indent correctly. It really helps when reading your code.

  19. #39
    JosAH's Avatar
    JosAH is offline Moderator
    Join Date
    Sep 2008
    Location
    Voorschoten, the Netherlands
    Posts
    13,335
    Blog Entries
    7
    Rep Power
    20

    Default

    Quote Originally Posted by couling View Post
    Thanks for the link I'll read it tonight.

    No I don't know a language which does this. All the languages I know are unable to remove a lock because locking is not part of the core language. In other languages it is an external package. The optomiser does not know what the lock is for so must leave it in.

    In general though, a good compiler can move code around and even remove code as much as it likes internally as long as the end result can be mathmatically garunteed to be the same.
    Even more: most (if not all languages) leave the code in libraries alone; they simply trust on the API (in the .h header files for C like languages). If there is locking code in the code in the library it will be present in the final executable file (when the linker has done its evil deeds). Java is different here: it loads the code for, say, the Vector class and the Hotspot/JIT mechanism is free to play with it, alter it or whatever; again, as you wrote, the resulting code has to be functionally equivalent to the original byte code.

    kind regards,

    Jos
    cenosillicaphobia: the fear for an empty beer glass

  20. #40
    couling is offline Member
    Join Date
    Nov 2010
    Posts
    54
    Rep Power
    0

    Default

    Quote Originally Posted by couling View Post
    I'm trying very carefully to draw a line between what java does that could be implemented in a classic compiler and what it does that could not. Re-compiling the standard libraries is not common practise, true, but why is it impossible?
    To that end I've been hunting for comparisons between Java compiled nativly and Java HotSpot

    The only one I've found so far sadly can not be thought of as unbias. And there is no 64-Bit native compiler yet (as far as I know).
    A Java Compiler Performance Study - HotSpot, GCJ, Excelsior JET
    ----Signature ----
    Please use [CODE] tags and indent correctly. It really helps when reading your code.

Page 2 of 3 FirstFirst 123 LastLast

Similar Threads

  1. Java Code Won't Compile
    By JavaStudent1990 in forum New To Java
    Replies: 4
    Last Post: 07-29-2010, 09:34 AM
  2. New to JAVA and code cant compile
    By Gayethiri_86 in forum New To Java
    Replies: 2
    Last Post: 03-05-2010, 06:43 AM
  3. Replies: 6
    Last Post: 02-06-2009, 08:05 PM
  4. Compile/Execute code in Java app
    By Doctor Cactus in forum New To Java
    Replies: 5
    Last Post: 12-16-2008, 09:58 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •