Can java be speeded up this way

Discussion in 'Java' started by js_dev@rediffmail.com, Aug 31, 2005.

  1. Guest

    Hi all,
    Just skim through and if its an old, already-discarded idea, dont
    bother, just reply "old, discarded"

    Speeding up java:
    I feel that quite a large part of the java community is busy comparing
    IDEs and platforms and competitive open-scource products
    and not focussing on the basic problem which is speed of execution and
    memory footprint. I find most Java programs on my
    P4 2.4GHz, 512M, 80 GB HDD to be slow to start, especially the GUI. I
    am not sure of non-GUI because have not used any power programs, yes I
    once generated the entire java docs from the src.zip of Sun, but that
    took around 20 minutes or more.

    >From the little java I know, I can make the following conclusions:

    (1)Java is "cross-platform" <b>only</b> because of a universal bytecode
    specification.
    (2)This bytecode runs in every place where there is a JVM made for that
    platform which
    <i>basically hides the native part of the code</i>
    (3)What
    <i>actually carries the bytes/electronic signals to and from the
    memory</i>
    into the processor and harddisk is
    <i>very much native</i>
    code, but it is part of the JVM and transparent to the programmer/user
    and that's your platform-independence.
    (4)WORA(write once run anywhere) essentially refers to the bytecode
    specification and practically, only to the means of <i>distributing</i>
    binaries,
    <i>not the execution of the java code</i>.

    If we need to make java fast without losing cross-platform usability,
    one way that strikes me is to mark code to be made fast in your source
    as

    optimize{
    /* my code
    * to be optimized
    * goes here
    */
    }

    Just like we have synchronize{} and static{} and such others, we should
    add optimize{}.
    or

    <i>Maybe the optimization functionality should get added to all code
    internally by default, removing the syntax inconsistency</i>

    Q. But isn't this going to go right against Java's cross-platform
    usability and backward compatibility?
    No.
    The only modification in your source code is the word "optimize" and
    the two brace brackets(maybe not even that).

    Then, how will it actually optimize?

    Here, <i>the jvm needs modification</i>.
    Java packages
    <i>should continue to be distributed as they are being distributed
    today</i>
    -in the form of platform-independent jar and class files.
    <b><i>no change at all there.</i></b>
    However, a change in the JVM or an additional utility like jvmopt.dll,
    which is basically a parser, C/C++-style native compiler, linker,
    (all-in-one) which will reparse the bytecode - (if your machine has an
    older JDK installation, this dll will obviously be absent and your
    javac.exe will simply not optimize.

    However, if your machine has Java 7(for example), a "tmp-bin" directory
    will be created in which the code to be optimized
    will be compiled into native dll code or exe code (don't jump, just
    read to the end.....)
    <b><i>only for the time of execution </i></b>
    (and don't name the generated files .dll and .exe - basically to
    prevent rampant reverse engineering and corruption of executable
    formats) and then, when the execution is complete, this "tmp-bin"
    directory will be cleaned up automatically (del *.*).

    But jars and class files will continue to be <b>the same</b>.
    <b>this is the most important thing.</b>

    There is no change made to either the .class specification or the
    bytecode specification or the jar specification.

    The only changes are in
    (1)javac.exe and
    (2)java.exe and
    (3)an additional jvmopt.dll and
    (4)the "tmp-bin" directory.

    Clearly, this is a workaround and hardly elegant, but utilitarian
    nevertheless.

    I know that the JSR process will reject it outright, but maybe it can
    give some ideas to some experts.

    I would like to know what ( or maybe what all ) is wrong with the idea.

    Regards,
    Joseph S.
    , Aug 31, 2005
    #1
    1. Advertising

  2. On 31 Aug 2005 08:01:02 -0700, wrote:

    > Just skim through and if its an old, already-discarded idea, dont
    > bother, just reply "old, discarded"


    Search the group (I don't know or care if it's old or discarded,
    it is the OP's responsibility to do a search before posting).

    > ..<i>actually carries the bytes/electronic signals to
    > and from the memory</i>


    Italics? Cute. But this is usenet, and it sure don't render
    as HTML here.

    --
    Andrew Thompson
    physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
    "We are about to attempt a crash landing. Please extinguish all
    cigarettes.."
    Laurie Anderson 'From The Air'
    Andrew Thompson, Aug 31, 2005
    #2
    1. Advertising

  3. wrote:
    > Hi all,
    > Just skim through and if its an old, already-discarded idea, dont
    > bother, just reply "old, discarded"


    It's partly old (i.e. there is JIT already) and partly superfluous (i.e.
    HotSpot VM's will optimize the part of the code that is worhtwile
    optimizing). And AFAIK Java compilers do a certain degree of optimization
    themselves already. Short, not worth the effort to consider closely.

    Kind regards

    robert
    Robert Klemme, Aug 31, 2005
    #3
  4. On 2005-08-31, Andrew Thompson penned:
    > On 31 Aug 2005 08:01:02 -0700, wrote:
    >
    >> ..<i>actually carries the bytes/electronic signals to and from the
    >> memory</i>

    >
    > Italics? Cute. But this is usenet, and it sure don't render as
    > HTML here.


    There was bold, too. I saw little <i>s and <b>s scattered all about.

    Even if I were reading that email on paper, with all the italics and
    bolds and whatnot properly rendered, I would still say that he was
    overusing them.

    --
    monique

    Ask smart questions, get good answers:
    http://www.catb.org/~esr/faqs/smart-questions.html
    Monique Y. Mudama, Aug 31, 2005
    #4
  5. Oliver Wong Guest

    <> wrote in message
    news:...
    > optimize{
    > /* my code
    > * to be optimized
    > * goes here
    > */
    > }
    >
    > Just like we have synchronize{} and static{} and such others, we should
    > add optimize{}.
    > or
    >
    > <i>Maybe the optimization functionality should get added to all code
    > internally by default, removing the syntax inconsistency</i>


    If you just mark all code to be optimized by default, then that's the
    same as not marking any code and trying to optimize it all anyway, right?

    Anyway, good JVMs profile the code as it's running, detect which code is
    slow, and optimize that anyway. In theory, this dynamic optimization would
    even be better than statically marking the code for optimization. Let's say
    we both run the same word processor written in Java, except I almost only
    use the word processor in its "HTML output" mode, while you use it mainly
    for typing and printing up documents. The JVM would in theory notice this
    and optmize the "HTML code", possibly at the expense of the "printing code"
    for my copy of the program, and do the reverse for your program.

    > However, if your machine has Java 7(for example), a "tmp-bin" directory
    > will be created in which the code to be optimized
    > will be compiled into native dll code or exe code (don't jump, just
    > read to the end.....)


    As I mentioned above, in theory, dynamic compilation can yield faster
    code than static compilation in that the code can be optimized specifically
    for the way in the which the user uses the application. In practice, results
    haven't been so good, but they're still improving and I expect dynamic
    compilation to beat static compilation within the next few years.
    Oliver Wong, Aug 31, 2005
    #5
  6. Roedy Green Guest

    On 31 Aug 2005 08:01:02 -0700, wrote or quoted :

    >I know that the JSR process will reject it outright, but maybe it can
    >give some ideas to some experts.


    You can do that today if you have a little money. See
    http://mindprod.com/jgloss/nativecompiler.html

    http://mindprod.com/jgloss/jet.html

    There instruction for example to natively compile eclipse.

    However, the main reasons for Java's slowness is not caused by lack of
    native compilation. Once a Java server has been running for a while,
    it really rips. It is almost as fast as a native compiler. It natively
    compiles on the fly, sometimes faster, optimising using information it
    has gleaned watching the program run for a while. It even will treat
    as final and inline classes and methods not so marked, then change its
    mind if dynamic loading changes that assumption.

    The problem is waddling to its feet. It has to load many standard
    classes.

    Back in 1985, I invented gespenstering, taking two snapshots of a
    running program and turning them into a relocatable exe file. That
    way a program starts out with everything pre-loaded. This is the
    technique I use in the Abundance compiler to create fast-loading
    application exe files.

    The Sun runtime could use something similar.

    I have written two proposals to speed Java load up.

    See http://mindprod.com/projects/gespenster.html
    http://mindprod.com/projects/suspendedanimation.html

    Since I wrote them, Sun has put much of the JVM in a DLL. This helps
    somewhat speeding up subsequent JVM loads.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Aug 31, 2005
    #6
  7. Roedy Green Guest

    On Wed, 31 Aug 2005 15:10:20 GMT, Andrew Thompson
    <> wrote or quoted :

    >Italics? Cute. But this is usenet, and it sure don't render
    >as HTML here.


    How patronising. You completely ignored the point of his post. Surely
    all you can read basic html. It is as good a way as any for marking
    emphasis.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Aug 31, 2005
    #7
  8. Joan Guest

    <snip>
    > optimize{
    > /* my code
    > * to be optimized
    > * goes here
    > */
    > }


    Sure then I can do this
    ----------------------------
    for (
    optimize{
    int i=0;
    }
    i<5;i++) { int a = 5; }
    ----------------------------
    Joan, Sep 1, 2005
    #8
  9. Dale King Guest

    wrote:
    > Hi all,
    > Just skim through and if its an old, already-discarded idea, dont
    > bother, just reply "old, discarded"
    >
    > Speeding up java:
    > I feel that quite a large part of the java community is busy comparing
    > IDEs and platforms and competitive open-scource products
    > and not focussing on the basic problem which is speed of execution and
    > memory footprint. I find most Java programs on my
    > P4 2.4GHz, 512M, 80 GB HDD to be slow to start, especially the GUI. I
    > am not sure of non-GUI because have not used any power programs, yes I
    > once generated the entire java docs from the src.zip of Sun, but that
    > took around 20 minutes or more.
    >
    >>From the little java I know, I can make the following conclusions:

    > (1)Java is "cross-platform" <b>only</b> because of a universal bytecode
    > specification.
    > (2)This bytecode runs in every place where there is a JVM made for that
    > platform which
    > <i>basically hides the native part of the code</i>
    > (3)What
    > <i>actually carries the bytes/electronic signals to and from the
    > memory</i>
    > into the processor and harddisk is
    > <i>very much native</i>
    > code, but it is part of the JVM and transparent to the programmer/user
    > and that's your platform-independence.
    > (4)WORA(write once run anywhere) essentially refers to the bytecode
    > specification and practically, only to the means of <i>distributing</i>
    > binaries,
    > <i>not the execution of the java code</i>.
    >
    > If we need to make java fast without losing cross-platform usability,
    > one way that strikes me is to mark code to be made fast in your source
    > as
    >
    > optimize{
    > /* my code
    > * to be optimized
    > * goes here
    > */
    > }
    >
    > Just like we have synchronize{} and static{} and such others, we should
    > add optimize{}.
    > or
    >
    > <i>Maybe the optimization functionality should get added to all code
    > internally by default, removing the syntax inconsistency</i>
    >
    > Q. But isn't this going to go right against Java's cross-platform
    > usability and backward compatibility?
    > No.
    > The only modification in your source code is the word "optimize" and
    > the two brace brackets(maybe not even that).
    >
    > Then, how will it actually optimize?
    >
    > Here, <i>the jvm needs modification</i>.
    > Java packages
    > <i>should continue to be distributed as they are being distributed
    > today</i>
    > -in the form of platform-independent jar and class files.
    > <b><i>no change at all there.</i></b>
    > However, a change in the JVM or an additional utility like jvmopt.dll,
    > which is basically a parser, C/C++-style native compiler, linker,
    > (all-in-one) which will reparse the bytecode - (if your machine has an
    > older JDK installation, this dll will obviously be absent and your
    > javac.exe will simply not optimize.
    >
    > However, if your machine has Java 7(for example), a "tmp-bin" directory
    > will be created in which the code to be optimized
    > will be compiled into native dll code or exe code (don't jump, just
    > read to the end.....)
    > <b><i>only for the time of execution </i></b>
    > (and don't name the generated files .dll and .exe - basically to
    > prevent rampant reverse engineering and corruption of executable
    > formats) and then, when the execution is complete, this "tmp-bin"
    > directory will be cleaned up automatically (del *.*).
    >
    > But jars and class files will continue to be <b>the same</b>.
    > <b>this is the most important thing.</b>
    >
    > There is no change made to either the .class specification or the
    > bytecode specification or the jar specification.
    >
    > The only changes are in
    > (1)javac.exe and
    > (2)java.exe and
    > (3)an additional jvmopt.dll and
    > (4)the "tmp-bin" directory.
    >
    > Clearly, this is a workaround and hardly elegant, but utilitarian
    > nevertheless.
    >
    > I know that the JSR process will reject it outright, but maybe it can
    > give some ideas to some experts.
    >
    > I would like to know what ( or maybe what all ) is wrong with the idea.


    The part about marking it to be optimized is a bad idea of course, but
    the real kernel of the idea you are talking about is the caching the
    native compilation of the classes. And that idea is not new. It was
    actually supposed to originally be part of 1.5, but was removed very
    early on. Maybe it will appear in 1.6.

    In the proposal for 1.5 it basically cached the native compilation of
    the classes in the standard API. It did not apply to user classes.
    --
    Dale King
    Dale King, Sep 11, 2005
    #9
  10. Chris Smith Guest

    Dale King <> wrote:
    > The part about marking it to be optimized is a bad idea of course, but
    > the real kernel of the idea you are talking about is the caching the
    > native compilation of the classes. And that idea is not new. It was
    > actually supposed to originally be part of 1.5, but was removed very
    > early on. Maybe it will appear in 1.6.


    If this didn't make it into 1.5, then what is the classes.jsa file all
    about? I haven't been following JVM changes lately, but I assumed it
    was some kind of a cache of precompiled classes.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, Sep 11, 2005
    #10
  11. Roedy Green Guest

    On Sun, 11 Sep 2005 03:20:34 GMT, Dale King
    <> wrote or quoted :

    >> (1)Java is "cross-platform" <b>only</b> because of a universal bytecode
    >> specification.


    That is a small fraction of the reason. The bulk of the work is in
    the native methods that have been hand implemented on every platform.

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Sep 11, 2005
    #11
  12. Roedy Green Guest


    >> Then, how will it actually optimize?


    Oddly, the trend has been to less and less optimisation of the byte
    code. The reason is, compiling mindlessly makes things easier for the
    machine code optimiser later on. It makes it easier to recognise
    common patterns.

    This is fine for HotSpot, but makes things worse for the tiny JVMs
    that interpret. They need a byte code optimiser.

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Sep 11, 2005
    #12
  13. Chris Smith Guest

    Roedy Green <> wrote:
    > On Sun, 11 Sep 2005 03:20:34 GMT, Dale King
    > <> wrote or quoted :
    >
    > >> (1)Java is "cross-platform" <b>only</b> because of a universal bytecode
    > >> specification.

    >
    > That is a small fraction of the reason. The bulk of the work is in
    > the native methods that have been hand implemented on every platform.


    I'd add cross-platform API design as well. Various standard APIs in
    Java are (whether elegantly or otherwise) explicitly designed for the
    ability to write cross-platform code. Without that, bytecode and native
    methods wouldn't make much difference.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, Sep 11, 2005
    #13
  14. Chris Smith wrote:
    >
    > If this didn't make it into 1.5, then what is the classes.jsa file all
    > about? I haven't been following JVM changes lately, but I assumed it
    > was some kind of a cache of precompiled classes.


    It's essentially rt.jar loaded into an internal, architecture-dependent
    format. I believe with methods, fields and type references linked,
    vtable equivalents, all string constants interned, etc.

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Sep 11, 2005
    #14
  15. Dale King Guest

    Chris Smith wrote:
    > Dale King <> wrote:
    >
    >>The part about marking it to be optimized is a bad idea of course, but
    >>the real kernel of the idea you are talking about is the caching the
    >>native compilation of the classes. And that idea is not new. It was
    >>actually supposed to originally be part of 1.5, but was removed very
    >>early on. Maybe it will appear in 1.6.

    >
    >
    > If this didn't make it into 1.5, then what is the classes.jsa file all
    > about? I haven't been following JVM changes lately, but I assumed it
    > was some kind of a cache of precompiled classes.


    Don't know. I know I read about it very early on in the list of features
    for 1.5 and thought it was a great idea. A while back I was going to
    reply to a post about this feature and was looking up the link to the
    feature from the 1.5 docs only to discover that there was no listing of
    the feature in the docs. Unfortunately, you can only download the latest
    version of the feature list, but the feature is no longer in the document.


    --
    Dale King
    Dale King, Sep 12, 2005
    #15
  16. Dale King Guest

    Dale King wrote:
    > Chris Smith wrote:
    >
    >> Dale King <> wrote:
    >>
    >>> The part about marking it to be optimized is a bad idea of course,
    >>> but the real kernel of the idea you are talking about is the caching
    >>> the native compilation of the classes. And that idea is not new. It
    >>> was actually supposed to originally be part of 1.5, but was removed
    >>> very early on. Maybe it will appear in 1.6.

    >>
    >>
    >>
    >> If this didn't make it into 1.5, then what is the classes.jsa file all
    >> about? I haven't been following JVM changes lately, but I assumed it
    >> was some kind of a cache of precompiled classes.

    >
    >
    > Don't know. I know I read about it very early on in the list of features
    > for 1.5 and thought it was a great idea. A while back I was going to
    > reply to a post about this feature and was looking up the link to the
    > feature from the 1.5 docs only to discover that there was no listing of
    > the feature in the docs. Unfortunately, you can only download the latest
    > version of the feature list, but the feature is no longer in the document.


    Found this about it:

    http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html

    Perhaps I was premature saying it didn't make it in.

    --
    Dale King
    Dale King, Sep 12, 2005
    #16
  17. Guest

    hi all,
    thanks for all the replies.
    The classes.jsa file was exactly the thing I was trying to arrive at -
    so, essentially what I initiallly thought to be an ugly workaround is a
    part of Java 5 (!!). On the other hand, I feel, one must read all the
    documentation patiently and intelligently - it gives all the answers,
    more or less.
    , Sep 17, 2005
    #17
  18. Roedy Green Guest

    On 17 Sep 2005 09:51:43 -0700, wrote or quoted :

    > On the other hand, I feel, one must read all the
    >documentation patiently and intelligently - it gives all the answers,
    >more or less.


    If you read all the docs you would never have any time to write code.
    We need a new type of FILTERED documentation that does its best not to
    tell you something you already know or that is obvious, but at the
    same time avoids telling you about esoterica unless you request that
    level of detail.

    There were a group of French mathematicians who wrote under the name
    Bourbaki. They had a convention of putting a slippery road sign next
    to points there were unexpected, or treacherous.

    Computer documentation could greatly benefit from this convention.
    Most of it is reams and reams of the obvious, with tiny dots of
    surprise.

    I wrote an essay on how it might work. See
    http://mindprod.com/jgloss/author.html
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Sep 19, 2005
    #18
  19. Oliver Wong Guest

    "Roedy Green" <> wrote in message
    news:eek:...
    > If you read all the docs you would never have any time to write code.
    > We need a new type of FILTERED documentation that does its best not to
    > tell you something you already know or that is obvious, but at the
    > same time avoids telling you about esoterica unless you request that
    > level of detail.
    >
    > There were a group of French mathematicians who wrote under the name
    > Bourbaki. They had a convention of putting a slippery road sign next
    > to points there were unexpected, or treacherous.
    >
    > Computer documentation could greatly benefit from this convention.
    > Most of it is reams and reams of the obvious, with tiny dots of
    > surprise.
    >
    > I wrote an essay on how it might work. See
    > http://mindprod.com/jgloss/author.html


    Very interesting idea. I like how the topics are rated by various
    metrics of difficulty. However, there is the issue that some of these values
    may be very strongly influenced by the intent of the reader. The information
    that compiler writers and virtual machine writers needs will probably be
    esoteric from the point of view of someone who only wants to program in the
    damn language, that's a given.

    But there may be information that's esoteric from the point of view of
    the compiler writer which is basic from the point of view of the virtual
    machine writer, and vice versa. That is to say, there isn't a total ordering
    on this set of values, so I'm not sure using numbers (which ARE totally
    ordered) is the best representation.

    Perhaps an icon system, where the icons represent intent. E.g. the
    semantics of one particular icon might be "If you're a compiler writer, you
    need to read this!"

    - Oliver
    Oliver Wong, Sep 19, 2005
    #19
  20. Roedy Green Guest

    On Mon, 19 Sep 2005 18:30:17 GMT, "Oliver Wong" <>
    wrote or quoted :

    > Very interesting idea. I like how the topics are rated by various
    >metrics of difficulty. However, there is the issue that some of these values
    >may be very strongly influenced by the intent of the reader. The information
    >that compiler writers and virtual machine writers needs will probably be
    >esoteric from the point of view of someone who only wants to program in the
    >damn language, that's a given


    one idea is that readers are constantly giving feedback to the authors
    and the system as a whole. What did they understand, what was
    baffling, what was obvious.

    You then can develop profiles of readers, and use AI to figure out
    which profile or group of readers you fit into. Decisions on what to
    show are based on what other people like you found easy or hard.

    It also lets the authors know where they need to augment, clarify,
    prune, add examples etc.

    The key is you can have one document that truly is useful to a novice
    and expert, and to a novice who gradually becomes an expert. The book
    adjusts to him as his competence level increases.

    I think of how often I read a book and go yeah, yeah, yeah, yeah, OOPS
    what was THAT? I have to stay awake. Getting the yeah, yeahs out the
    way or at least marking them as such so I can just skim them leaves me
    free to pay attention to the tricky stuff.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Sep 20, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page