[jsr294-modularity-eg] Static compilation

[Alex Buckley]

(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