[jsr294-modularity-eg] Static compilation

[Glyn Normington]

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20070501/ba0a25b4/attachment.html