Model 3 classfile design document
brian.goetz at oracle.com
Wed Feb 10 20:52:01 UTC 2016
I see, yes, I goofed in those lines. I guess I was eager to explicate ArrayType and didn’t type-check the results….
R(Foo<int>) should be just ParamType[LFoo, _].
On Feb 10, 2016, at 8:05 PM, Bjorn B Vardal <bjornvar at ca.ibm.com> wrote:
> Thanks! That matches the behaviour I would expect.
> The piece in the document that led me to the different understanding of point 3/4 was point 4 in the examples on page 4:
> R(Foo<int>) = ParameterizedType['L', "Foo", ArrayType[1, "I"]]
> According to point 3 and 4 in your answer, this should be:
> R(Foo<int>) = ParameterizedType['L', "Foo", "_"]
> And just to confirm, not the following:
> R(Foo<int>) = ParameterizedType['L', "Foo", ArrayType[1, "_"]]
> Bjørn Vårdal
> ----- Original message -----
> From: Brian Goetz <brian.goetz at oracle.com>
> To: Bjorn B Vardal/Ottawa/IBM at IBMCA
> Cc: valhalla-spec-experts at openjdk.java.net
> Subject: Re: Model 3 classfile design document
> Date: Wed, Feb 10, 2016 11:51 AM
> So, there’s two layers to this:
> - What can you express in the bytecode;
> - What will javac emit
> We want the VM to be as dumb as possible with respect to parameterization and erasure. Therefore, we don’t ask the VM to reason about things like “ref types are erased”; the language compiler asks for either reification or erasure, and the VM happily complies. So ParamType[List, String] is a reified List<String>, and ParamType[List, erased] is an erased List.
> Javac will likely never emit reified generics over references, but other languages could.
> To your examples:
> 1. Javac will emit ParamType[Foo, erased]
> 2. Javac will emit ParamType[Foo, int] (reified)
> 3. Javac will emit ParamType[Foo, erased] (since int is a reference type)
> 4. Javac will emit ParamType[Foo, erased] (same)
> Did I make a mistake in the doc that suggested otherwise for 3/4? Please correct me!
> On Feb 10, 2016, at 3:50 PM, Bjorn B Vardal <bjornvar at ca.ibm.com> wrote:
>> I have a question about reifying array types. This is what I understand is the proposed behaviour:
>> Foo<String> - Reference, so erased
>> Foo<int> - Primitive, so reified
>> Foo<int> - In the Model 3 Classfile Design document, this is reified.
>> Foo<String> - Unclear - erased as reference, or reified as array?
>> The first two are quite clear, but I'm wondering about 3 and 4. What is the reason for reifying the int in the Model 3 document? Considering that both int and String are subclasses of Object, can we not erase array types? If we can't erase them, does that apply to reference arrays as well, e.g. String?
>> Bjørn Vårdal
>> ----- Original message -----
>> From: Brian Goetz <brian.goetz at oracle.com>
>> Sent by: "valhalla-spec-experts" <valhalla-spec-experts-bounces at openjdk.java.net>
>> To: valhalla-spec-experts at openjdk.java.net
>> Subject: Model 3 classfile design document
>> Date: Fri, Jan 22, 2016 11:53 AM
>> Please find a document here:
>> 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>
More information about the valhalla-spec-observers