Model 3 classfile design document

[Brian Goetz]

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
>> Cc:
>> Subject: Model 3 classfile design document
>> Date: Fri, Jan 22, 2016 11:53 AM
>>  
>> 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>
>> 
>>  
>>  
> 
>  
>