Yes, we should be able to work with the lower range.
- Original message -From: Karen Kinnear To: Bjorn B Vardal Cc: valhalla-spec-experts@openjdk.java.netSubject: Re: MVT change in new opcode numbers?Date: Thu, Jul 27, 2017 3:10 PM Sigh - it does matter to us where it starts - we do
If you want to make it contiguous, does it matter to you (HotSpot) where it starts? If not, the most practical for us would be 217-225. If that doesn't work, I believe we'll be able to work with 203-211.
- Original message -From: Karen Kinnear Sent by: "valhalla-spec-experts" To: valhalla
> Bjorn: single representation for both value capable class and derived value class
We basically rely on single class data structure for the VCC and DVT, but we still expose these as separate java/lang/Class objects.
> I think you said “treat ;Q” as the name for the derived value class ra
> value field: (ambig.) field whose type is a value type (in any kind of class) OR a field in a value class (of any type)
If you want to resolve this ambiguity, I've been referring to the former as a "value typed field" and the latter as a "value field".
- Original message -From: John R
In one of the MVT review meetings, Doug Lea requested a document that outlines the differences between Valhalla MVT and IBM's Packed Objects. Packed Objects was an evaluation technology in the IBM SDK for Java 8.
I have attached the completed outline, which was written by Dan Heidinga and myself.
I'm writing up my notes from the meeting, and I have a question about the box's no-arg constructor. My notes say that this constructor is automatically provided and may not be replaced by the user. My understanding is that this is done in order to force the constructor to have the same behaviour a
Karen / John: Can you clarify this? Do you mean that they will only be flattened when created using the reflection / MethodHandle API?
> John: MVT 1.0 will only flatten arrays reflectively
--
Bjørn VårdalJ9 Java Virtual Machine DeveloperIBM Runtimes
- Original message -From: Karen K
I have a question regarding overriding instance generic methods.
class Foo { void m(T t) {}}
class Bar extends Foo { @Override void m(T t) {}}
class Test {
void test() {
Foo f = new Bar();
f.m(42);
}
}
I think this is the translation we've been talking abo
I'd like to go into a bit more detail about why these consequences exist. Hopefully that will tell us whether we agree on the reasoning behind this list.
> Alpha-renaming a type variable (to a non-shadowed name) should be binary and source compatible.
The name is only used internally in the gener
Will the users be able to write their own ?
class Foo {
__species {
... } }
Your access bridge solution using species methods looks fine, but are we not solving that with nest ma
Specialization statics
The problem
In the old world, there are two possible member placements: static and instance. Static members have traditionally been described as “members on the class”, and we all assumed we understood what “class” meant. However, “class” is a heavily overloaded term, and it’
We agree that the potential source incompatibility is an acceptable price for the reduced bytecode complexity in Model 5. If the source incompatibility turns out to be more severe than expected, does it make more sense to bring back separate wildcards (?/ref, any), rather than bringing back the byt
Applicability check
> When loading a parameterization of a generic class, we perform an applicability check for each member as we
> encounter it; in the model outlined here, this is a straight subtyping check of the current parameterization against
> the restriction domain.
In order to support th
be fine in the empty collection case, but what about cases where the static field is public? We can't control those usage sites.
--Bjørn Vårdal
- Original message -From: Remi Forax To: Valhalla Expert Group Observers Cc: Bjorn B Vardal/Ottawa/IBM@IBMCASubject: Re: Classes,
ation.Rémi- Mail original -----> De: "Brian Goetz" > À: "Bjorn B Vardal" > Cc: valhalla-spec-experts@openjdk.java.net> Envoyé: Mardi 23 Février 2016 01:23:16> Objet: Re: Classes, specializations, and statics>> It's possible that there could be mult
ions) don't appear to have specialized statics. Do we want to put erasure in the face of users like this? It seems better to let the users deal purely with parameterizations, and we let specialization and erasure be implementation details.
--Bjørn Vårdal
- Original message -From:
class Collection { private __SS Collection emptyCollection = … // ACC_SS field emptyCollection : ParamType[Collection, TypeVar[T]] private __SS Collection emptyCollection() { return emptyCollection; } ACC_SS emptyCollection()ParamType[Collection, TypeVar[T]] { getstatic ParamType[Coll
nter comparison then a larger guid comparison. And I'd rather debug something with a name than matching guids.
--Bjørn Vårdal
- Original message -From: John Rose To: Peter Levart Cc: Brian Goetz , Bjorn B Vardal/Ottawa/IBM@IBMCA, valhalla-spec-experts@openjdk.java.netSubject: Re: Nes
ss access across all classes who's NestTop is null. We can do this by setting the NestTop to the class itself.
--Bjørn Vårdal
- Original message -----From: Brian Goetz To: Bjorn B Vardal/Ottawa/IBM@IBMCA, valhalla-spec-experts@openjdk.java.netCc:Subject: Re: NestmatesDate: Sat, Feb 13
The Top<->Child handshake only needs to happen when the Child is loaded (which will load Top as a dependency), and access request from Child1 to Child2 is reduced to Child1->nestTop == Child2->nestTop. This means that we can fail immediately if the handshake fails during class loading, i.e.
The class file design looks good. I have two questions:
Will the template class be accessible as a java/lang/Class (or equivalent) in its unspecialized form? If so, will any of the type variable information be made available through this class? We're wondering how much information needs to
in your answer, this should be:
R(Foo) = ParameterizedType['L', "Foo", "_"]
And just to confirm, not the following:
R(Foo) = ParameterizedType['L', "Foo", ArrayType[1, "_"]]
--Bjørn Vårdal
- Original m
I have a question about reifying array types. This is what I understand is the proposed behaviour:
Foo - Reference, so erasedFoo - Primitive, so reifiedFoo - In the Model 3 Classfile Design document, this is reified.Foo - Unclear - erased as reference, or reified as
23 matches
Mail list logo
