> 4. arrays
> We need a new bytecode to create a flattenable/non-nullable array
> existing bytecodes do not create flattenable arrays with the new model of
container marking flattenable
> rather than by type
On a related note, it might be worth it to also consider the implication of
flattened arra
I would like to propose an alternative strategy, one that would effectively
provide the same consistency checks outlined in
http://cr.openjdk.java.net/~acorn/value-types-consistency-checking-details.pdf
without requiring eager loading of value types (VT) in the return/args of
methods during the pr
aves.
--Tobi
> From: Remi Forax
> To: John Rose
> Cc: Tobi Ajila , valhalla-spec-experts
>
> Date: 2018/07/10 05:44 AM
> Subject: Re: EG help please with getting to LW1 re: Value Types
> Consistency Checking
>
> Hi all,
>
> De: "John Rose"
> À:
Hi John
Given that inline types can be flattened there is a possibility that data
races will occur in places where users were not expecting it before. So
your `__AlwaysAtomic` modifier is a necessary tool as the existing spec
will only enforce atomicity for 32bit primitives and references. I just
y to the
withfield bytecode?
--Tobi
> From: John Rose
> To: Tobi Ajila
> Cc: valhalla-spec-experts
> Date: 2020/01/13 05:03 PM
> Subject: [EXTERNAL] Re: atomicity for value types
>
> On Jan 13, 2020, at 1:44 PM, Tobi Ajila wrote:
> >
> > Hi John
> >
Hi Brian
Thanks for the updated SoV docs. In section 4, it mentions:
> In most cases, such as field descriptors and method descriptors, uses of
C.ref is translated as LC$ref;, uses of C.val is translated as QC$val;,
In the LW2 spec the `name_index` in `CONSTANT_Class_info` structures could
ref
Hi Dan S.
>>> - Where necessary (depending on the operations being performed), the
compiler generates conversions between 'I' and 'java/lang/Integer$val'. 'I'
is preferred wherever possible.
>>
>> We have to use QInteger$val whenever we use int as a type parameter, the
rest of the time, we can use
> Because arrays have identity (not to mention potentially large copying
costs), there is simply no reasonable conversion we can define; any
"conversion" would involve copying all the data, changing identity, or
both. Just as with the array subtyping requirements (Point[] <: Point.ref
[] <: Obje
Thanks for the example Dan, this "Object[] objs = arr; // just like Point[]
<: Object[]" makes it very clear. Brian's response makes more sense to me
now.
> From: Dan Smith
> To: Tobi Ajila
> Cc: Brian Goetz , valhalla-spec-experts
> , valhalla-spec-experts
> Bucket #3 classes must be reference-default, and fields/arrays of their
inline type are illegal outside of the declaring class. The declaring class
can provide a flat array factory if it wants to. (A new idea from Tobi,
he'll write it up for the thread.)
```
public sealed abstract class LegacyTy
10 matches
Mail list logo
