|
|
Re: Eric Bruno on the G1 Garbage Collector in JDK 6
|
Posted: Sep 1, 2009 4:54 AM
|
|
> Achilleas -
>
> > Do you have any idea of how efficient escape analysis
> can
> > be on Java? does it equal hand-coded value types in
> C++?
>
> I do not believe that Java (and any similar runtimes) can
> ever match C/C++ code for speed *if* the C/C++ code is
> well implemented, and the design/coding is based on a
> realistic runtime profile. In other words, if you can
> build a C/C++ system as if it had been iteratively
> designed / implemented / profiled (repeat ad nauseum)
> until it couldn't be any faster, then that's likely to be
> unbeatable by any language runtime machine (e.g. JVM).
>
> For relatively small projects, with engineering teams made
> up of skilled coders with sufficient domain knowledge,
> this is quite do-able (because the profile can be
> intelligently postulated up front).
>
> For larger projects, and/or teams without intricate coding
> skills, I think it's unsafe (code-wise), risky
> (project-wise) and expensive (resource-wise) to attempt
> this.
>
> Advances such as runtime profiling (e.g. Hotspot) combined
> with automatic GC and escape analysis allow a language
> runtime machine to make this trade-off at runtime, i.e. to
> burn CPU cycles and memory to do this analysis and work as
> the application executes, instead of at development time.
>
> For the simplest systems, such as those that run for a
> short duration, the start-up costs (CPU and memory) and
> the deferred returns from profile-based optimizations make
> it clear that this approach is hugely inefficient. (You
> can clearly see this in language performance comparisons
> that include JVM start-up time as part of the measurement
> for programs that run for a fraction of a second.)
>
> For larger systems, and for systems that run for long
> periods of time, the start-up costs are amortized to
> near-zero, and the returns from profile-based
> optimizations are near-impossible to replicate by hand
> coding.
I agree with the above, it seems obvious.
>
> What we lack today is a language / language runtime
> machine that combines the two. Java has a number of design
> flaws (and even more implementation flaws) that
> cumulatively saddle it with start-up processing costs --
> and a significant minimum footprint in terms of memory --
> that eliminate it from a large class of applications.
I couldn't agree more. There is a need for a new programming language with the characteristics you mention.
D is not up to the task yet; it needs to mature a lot.
> I don't personally believe that C/C++ are remotely usable
> for modern application development (an opinion that is
> obviously not universally shared ;-).
Indeed. Even if modern C++ techniques are used (shared pointers, for example), there is still the problem of arrays/pointers and out-of-bounds indexing, which is a major problem. It takes a lot of discipline to use the appropriate classes, but then again you are bounded by the discipline of the developers of the libraries you use.
>
> A language / language runtime _similar_ to Java (etc.)
> could address most of the issues, but it would have to be
> _designed_ to solve them.
And also this language should have a better type system - something like C++ concepts.
Anyone up for the task? :-)
|
|
Previous Topic
