[jsr294-modularity-eg] Static compilation

Tue May 1 13:33:07 EDT 2007

Glyn, thanks for forwarding!  It is an interesting post and it is a
good point that Java modules may make it easier to guess that methods
are effectively final but I'm not sure if it can be easily assumed to
be a guarantee.  We haven't talked about such details but my
assumption was that it should be possible to dynamically load a class
that extends any non-final class including those classes that are not
exported.  Perhaps this is a good time to discuss this minor issue.
Have you all had the same expectation?  If this is the case then
modules would not provide the guarantee that Rob is after.

Incidentally, it is a common misconception that AOT compilation's goal
is always to improve performance.  This is a goal for some
implementations but in many cases, a good JIT technology can provide
as good or better performance given the same source code.
Specifically (at least in the past) runtime performance was a goal for
the .NET prefit only in the sense of the startup time (where it indeed
provided impressive gains) but the steady state performance was
actually slower.  For instance slide 22 in this presentation:
http://research.microsoft.com/~zorn/mre04/PreJit%20Talk.ppt is very
clear by stating this as one of the costs of preJIT:

- Steady state performance
 - Slowdown due to indirections in code
  - ASP.net
   - V1: PreJit 7-12% slower
   - Whidbey: PreJit 2-5% slower
  - Bytemark
   -Whidbey: same performance
  - Future: PreJit will have better performance

This shows BTW one of the hard things about measuring performance: it
really depends what you optimize for and many techniques benefit some
apps and some scenarios while hurting others.  In this example, many
people decided that a better startup is so important that the steady
state performance loss is a perfectly acceptable price to pay.

In my opinion modularity will not bring significant performance wins
in the steady state but it may allow improvements in start-up times.
But then predictions like this are notorious for being wrong.  :)

Michal

On 5/1/07, Glyn Normington <glyn_normington at uk.ibm.com> wrote:
>
> I don't know if EG members are following Rob's blog, but there is a sequel
> ([1]) which may be of interest.
>
> I haven't discussed this privately with Rob, but it seems to me that JSR 294
> as currently framed does help to determine when non-final methods are
> effectively final.
>
> If an unexported class in a superpackage is not extended by any other
> classes in the superpackage, then it cannot be extended by any classes
> outside the superpackage, since unexported classes cannot be referenced
> outside their enclosing superpackage.
>
>  Glyn
>
> [1]  http://robubu.com/?p=28
>
> Alex Buckley <Alex.Buckley at sun.com> wrote on 18/04/2007 15:12:21:
>
>
>  > (Reposting my answer)
>  >
>  > Glyn Normington wrote:
>  > > (I am re-posting this to the publicly visible mailing list for the
>  > > record. Please feel free to re-post responses.)
>  > >
>  > > The EG may be interested in Rob Yates's comments on JSR 294 ([1]). I'm
>  > > not sure I go along with the static compilation approach, but it's an
>  > > interesting point this Expert Group should consider, especially if
> there
>  > > is potential for JSR 294 to enable additional JIT optimisations.
>  > >
>  > > Glyn
>  > >
>  > > [1] http://robubu.com/?p=27
>  >
>  > I feel Rob is conflating different kinds of program analysis:
>  >
>  > - First, he considers "classic" analyses like control-flow analysis
>  > (including method inlining). I disagree with his statements that "They
>  > [CLI implementations] can do this [apply classic compiler optimizations]
>  > as most of the CLI languages have been designed for compilation using
>  > classic analysis techniques."  C# itself is no more or less designed for
>  > these analyses than Java. And JVMs can perform classic analyses on
>  > bytecode even in the presence of lazy class/module loading; they just
>  > have to be prepared for the results to be invalidated by further
>  > class/module loading. (C.f. deoptimization when a monomorphic call
>  > transform is no longer valid.)
>  >
>  > - Second, he considers dependency analysis on which AOT compilation
>  > relies. Here, here is on firm ground: an assembly's dependencies on
>  > other assemblies are fully specified in its metadata, so the AOT
>  > compiler ("ngen") can identify not just which class names are referenced
>  > by the class being compiled (easy enough to do for Java bytecode too)
>  > but also which exact assembly will provide the implementations of those
>  > classes.
>  >
>  > An assembly's metadata is not unlike the information we are proposing
>  > for a superpackage declaration, so everything should be in place for
>  > what Remi wants [1] if a superpackage is deployed as a 277-compliant
> module.
>  >
>  > Two points about AOT compilation itself:
>  >
>  > - It isn't static linking, so you still have a bunch of assemblies lying
>  > around on disk that must be consistent with each other and found by the
>  > VM according to some eager/lazy loading policy.
>  >
>  > - Code which uses reflection makes things difficult. The AOT compiler -
>  >   which is supposed to resolve an assembly's dependencies on other
>  > assemblies - cannot in general detect the use of assemblies loaded by
>  > reflection. So at runtime, an assembly A can be loaded by the system,
>  > but another assembly A can also be loaded by reflection from another
>  > location. .NET goes to a lot of trouble to keep the two A's separate by
>  > introducing "contexts" [2]. I don't know how Mono handles this issue.
>  >
>  >
> [1]http://weblogs.java.net/blog/forax/archive/2006/10/jsr_277_and_ahe.html
>  >
> [2]http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx
>  >
>  > Thanks,
>  > Alex
>  > _______________________________________________
>  > jsr294-modularity-eg mailing list
>  > jsr294-modularity-eg at cs.oswego.edu
>  >
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>
>
>
>  ________________________________
>
>
>
>
> Unless stated otherwise above:
>  IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
>  Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
>
>
>
>
>
>
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>
>