Model 3 classfile design document (original) (raw)

Brian Goetz brian.goetz at oracle.com
Mon Feb 1 21🔞06 UTC 2016

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) = Class["Foo"] or ParameterizedType['L', "Foo", ""] R(Foo) = 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

-- 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

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20160201/dc9dfa18/attachment.html>

More information about the valhalla-spec-experts mailing list