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 <[email protected]> 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 <[email protected]> > To: Bjorn B Vardal/Ottawa/IBM@IBMCA > Cc: [email protected] > 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 <[email protected]> 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 <[email protected]> >> Sent by: "valhalla-spec-experts" >> <[email protected]> >> To: [email protected] >> 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> >> >> >> > > >
