Can java be speeded up this way

[js_dev]

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.

 

[Andrew Thompson]

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'

 

[Robert Klemme]

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

 

[Monique Y. Mudama]

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.

 

[Oliver Wong]

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.

 

[Roedy Green]

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.

 

[Roedy Green]

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.

 

[Joan]

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; }
----------------------------

 

[Dale King]

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.

(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.

 

[Chris Smith]

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

 

[Roedy Green]

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.

 

[Roedy Green]

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.

 

[Chris Smith]

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

 

[Thomas Hawtin]

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

 

[Dale King]

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]

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.

 

[js_dev]

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.

 

[Roedy Green]

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

 

[Oliver Wong]

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

 

[Roedy Green]

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.