Model 3 classfile design document

[Brian Goetz]

In the current translation proposal, it is a real class.  That said, the generic method translation is the weakest part of the current proposal, in that it is more similar to Model 1 than Model 3.  In particular, the dispatch characteristics for instance generic methods are not currently very attractive — but we are actively looking for something better.  But in the meantime, we have something that works acceptably for prototyping.  

On Feb 1, 2016, at 5:44 AM, Andrey Breslav <andrey.breslav at jetbrains.com> wrote:

> Another question on the "Generic Methods" section: does the proposed encoding mean a new class file per generic method? Or is it purely about "fake" class-like entries in the CP of the enclosing class?
> 
> On Mon, Feb 1, 2016 at 8:33 AM Andrey Breslav <andrey.breslav at jetbrains.com> wrote:
> A question about these examples:
> R(Foo<raw>) = Class["Foo"] or ParameterizedType['L', "Foo", "_"]
> R(Foo<String>) = Class["Foo"] orParameterizedType['L', "Foo", "_"]
> R(Foo<int[]>) =ParameterizedType['L', "Foo", ArrayType[1, "I"]]
> Apparently, we want to preserve the information about int[], while we don't care about String. Why? Isn't int[] just a class, like String?
> 
> On Fri, Jan 22, 2016 at 7:53 PM Brian Goetz <brian.goetz at oracle.com> wrote:
> Please find a document here:
> 
> http://cr.openjdk.java.net/~briangoetz/valhalla/eg-attachments/model3-01.html
> 
> that describes our current thinking for evolving the classfile format to
> clearly and efficiently represent parametric polymorphism.  The early
> concepts of this approach were outlined in my talk at JVMLS last year;
> this represents a refinement of those ideas, and a reasonable "stake in
> the ground" description of what seems the most sensible way to balance
> preserving parametric information in the classfile without imposing
> excessive runtime costs for loading specializations.
> 
> We're working on an updated compiler prototype which people will be able
> to play with soon (along with a formal model.)
> 
> Please ask questions!
> 
> Some things this document does not address yet:
>   - How we deal with types implicit in the bytecodes (aload vs iload)
> and how they get specialized;
>   - How we represent restricted methods in the classfile;
>   - How we represent the wildcard type Foo<any>
> 
> 
> -- 
> Andrey Breslav
> Project Lead of Kotlin
> JetBrains
> http://kotlinlang.org/
> The Drive to Develop
> -- 
> Andrey Breslav
> Project Lead of Kotlin
> JetBrains
> http://kotlinlang.org/
> The Drive to Develop