The Great Startup Problem

[Per Bothner]

On 08/24/2014 11:25 AM, Charles Oliver Nutter wrote:
> On Sun, Aug 24, 2014 at 12:02 PM, Per Bothner <per at bothner.com> wrote:
>> (1) Kawa shows you can have dynamic languages on the JVM that both
>> run fast and have fast start-up.
>
> Like Clojure, I'd only consider Kawa to be *somewhat* dynamic. Most
> function calls can be statically dispatched, no?

In typical programs, written reasonably modularly, yes.
In heavily functional styles, or with heavy use of eval or old-fashioned
dynamic load (which some people like to do though I discourage it), less so.

Regardless, there will be much less search: Even when calling an unknown
function (i.e. apply), though there is some overhead for indirection and
dynamic argument-checking, there is normally just a single method to call.

I think it's a poor
> comparison to languages that have fully dynamic method lookup at all
> (or most) sites.
>
>> (2) Other dynamic languages (Ruby, JavaScript, PHP) have had more problems,
>> possibly because they are "too dynamic".  Or perhaps just their kind of
>> "dynamicism" is a poor match for the JVM.
>
> They're not "too dynamic"...they're "pervasively dynamic".

Which I'd argue is "too dynamic", unless it can be shown that
"pervasively dynamic" improves productivity or code quality.  I'm skeptical, but
smart people have and will continue to disagree on this.

>> (5) It is reasonable to continue to seek improvements in invokedynamic,
>> but in terms of resource prioritization other enhancement in the Java
>> platform
>> (value types, tagged values, reified generics, continuations, removing class
>> size
>> limitations, etc etc) are more valuable.
>
> Many of which will probably use invokedynamic in some form under the
> covers.

When you have a hammer ....  I'm dubious using invokedynamic is the
best approach for these tasks, though it might be somewhat involved.

> Getting invokedynamic solid, fast, and predictable should be
> priority one for JVM hackers right now.

I disagree, but I'm not the one doing the work or funding it.

You yourself say that's not the major problem you have with JRuby startup.

> Note that all Ruby applications
> boot from source every time they start up.

That seems losing.  Do you mean that pre-compilation (to classes)
isn't practical, or it isn't part of the culture?

> * An AST-based interpreter (JRuby 1.7). ....
> * An IR-based interpreter (JRuby 9000). ...

Kawa never interprets, even for 'eval', except for (1) evaluating
syntax-case macros at compile-time, or (2) for eval/load on platforms
like Android where the compiler isn't available at run-time.

> * All the core classes of Ruby. The String class in JRuby 9000 is
> nearly 6600 lines of code. The Array class is nearly 4500. And so on.
> Ruby provides an extremely rich set of core functionality at boot
> time, without requires or imports.

These seem to be compiled in advance, but that would still require linking or
other initialization, right?

> Now of course much of this is magnified with booting a large
> application. Tom Enebo ran some numbers and determined that running
> unit tests for a bare Rails app (which involves booting Rails, loading
> the build framework code, loading the test framework code, loading the
> applicaiton, and loading the tests) defines another 4600 methods,
> representing hundreds of .rb files and thousands of AST nodes. Most of
> this never JITs and runs cold every time.

Are you saying that when people run Rails, the entire Rails framework
is loaded from source each time?  Not even caching between runs?
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/