A plea to the JVM developers.more speed please

Ruby JRuby
1

Sorry if this is the wrong forum, I’m not sure where the right one is.
This is meant for the JVM developers/architects/designers…

My basic desire would be to somehow make java apps as fast as C ones,
esp. for starting up.

It seems to me that java apps run this way, on the hotspot server JVM:

start once, it runs, does warmup → bytecode, then runs fast, then
exits.

start again, it runs, does warmup → bytecode, then runs fast, then
exits.

Now assuming that it always has the same jars, shouldn’t it be able to
cache the JVM → bytecode “hot compilation” from one run to the next?
You know, something like GCC’s profile guided optimization option.
Something like icegrind’s optimized load time algorithm would be helpful
too [1]. I guess there’s a minijar maven plugin, but is there more?
(and minijar can’t be used in all cases).

Or perhaps there could be some magic made that’s like “take these jars,
convert them all into .so files that can interlink, and now java is a
fast loading as C is”? or “take these jars and this JVM, combine them
all into one lightning fast .exe file” or the like?

Is there anything out there like this? It’s the last hurdle preventing
java from becoming mainstream, I believe…

Pretty Please?

Ok that’s all I’m going to say.
Thanks!
-=r

[1]
http://blog.mozilla.com/tglek/2010/04/07/icegrind-valgrind-plugin-for-optimizing-cold-startup/#comment-31789

2

Have you ever heard of nailgun1?

3

nailgun looks like a clever idea. Kind of reminds me of spork or the
like.

Does it avoid sharing state across instances?

Now if only it could be adopted somehow the JVM team themselves and
integrated into core somehow…or maybe nailgun could have some
centralized server that was smart enough to “shut down” after many
seconds of unuse or the like…

It would also be ideal if running a server process in the background
weren’t necessary at all…I guess…kind of like how tomcat manages
several java apps at once…

Thanks!
-roger-

[1] Nailgun failed on Windows7 - JRuby - Ruby-Forum

4

My two cents on this is that the most common use case for Java programs
(and
probably any JVM based language) would be long running server side
applications. In this case the slow startup cost is so minimal compared
to
the life of the application that caching this information would not be
that
useful. I’m sure no one wants the startup to be slow, but most
developers
would prefer faster long term execution than faster startup.

Joe

5

On Wed, Sep 14, 2011 at 7:32 PM, Roger P. [email protected]
wrote:

Sorry if this is the wrong forum, I’m not sure where the right one is.
This is meant for the JVM developers/architects/designers…

Usually whatever means the team of the specific JVM you want to help
improve uses.

–
Phillip G.

gplus.to/phgaw | twitter.com/phgaw

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
– Leibniz

6

Hassan S. wrote in post #1021994:

Sorry, what? Could you explain what you mean by that? Given that
Tomcat is a server process, running in a JVM?

tomcat (I guess) has its own classloader so that it can load and unload
“sub-apps” (war files), so in a sense, it’s managing sub-java processes.
Ok so they happen to be in the same JVM but you know what I mean…

Joseph A. wrote in post #1021990:

My two cents on this is that the most common use case for Java programs
(and
probably any JVM based language) would be long running server side
applications.

Interestingly, the documentation to nailgun mentions something related:

"The Java language is mistakenly perceived by many as slow. In reality,
Java applications can perform extremely well - once they’re already
running. The startup time of the Java Virtual Machine (JVM) itself is at
best aggravating, and at worst sufficient reason not to use Java to
perform certain tasks. To Sun’s credit, this has improved with each
version of Java.

But it’s still annoying, and as a result Java has found a niche in
server-side applications that run for extended periods of time,
rendering the JVM startup time irrelevant. "

FWIW.

In this case the slow startup cost is so minimal compared
to
the life of the application that caching this information would not be
that
useful. I’m sure no one wants the startup to be slow, but most
developers
would prefer faster long term execution than faster startup.

Agree. We require speed “eventually” (except rubyists, but that’s a
different story). But you and I both agree that having both fast
startup and fast running would be ideal, I presume?

-roger-

7

On Wed, Sep 14, 2011 at 10:58 AM, Roger P. [email protected]
wrote:

It would also be ideal if running a server process in the background
weren’t necessary at all…I guess…kind of like how tomcat manages
several java apps at once…

Sorry, what? Could you explain what you mean by that? Given that
Tomcat is a server process, running in a JVM?

–
Hassan S. ------------------------ [email protected]

twitter: @hassan

8

On Thu, Sep 15, 2011 at 7:31 PM, Roger P. [email protected]
wrote:

Hassan S. wrote in post #1021994:

Sorry, what? Could you explain what you mean by that? Given that
Tomcat is a server process, running in a JVM?

tomcat (I guess) has its own classloader so that it can load and unload
“sub-apps” (war files), so in a sense, it’s managing sub-java processes.
Ok so they happen to be in the same JVM but you know what I mean…

This is correct. If anyone is interested in the details, they can be
found here:
http://tomcat.apache.org/tomcat-7.0-doc/class-loader-howto.html

running. The startup time of the Java Virtual Machine (JVM) itself is at

In this case the slow startup cost is so minimal compared
to
the life of the application that caching this information would not be
that
useful. I’m sure no one wants the startup to be slow, but most
developers
would prefer faster long term execution than faster startup.

Agree. We require speed “eventually” (except rubyists, but that’s a
different story). But you and I both agree that having both fast
startup and fast running would be ideal, I presume?

Initially I thought you just wanted to speed up JRuby’s start overhead
but the discussion revolves around making the JVM start faster. For
the latter this is certainly the wrong forum. But maybe there is a
way to get the former? Maybe the compiled form of a file (or even a
completeapplication) can be saved (e.g. serialized) in some cache
together with file modification time information. I have no idea
whether this is feasible though.

Kind regards

robert

–
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/