On 2/13/22 1:05 PM, Dan Smith wrote:
On Feb 12, 2022, at 10:16 PM, Srikanth Adayapalam
wrote:
I understand Frederic is asking about whether the spec inadvertently allows
something it should not - Here anyway is javac behavior:
Given:
abstract class A implements ValueObject {
int
There's a weird case that seems to be allowed by the Value Objects JVMS
draft:
An abstract class can declare non-static fields, which means it won't
have the ACC_PERMITS_VALUE flag set, but also declare that it implements
the ValueObject interface.
The combination looks just wrong, because no
This is probably a remain of the L/Q model, where a value class could be
referenced either as a L-type or a Q-type. L-Foo.x and Q-Foo.x pointed
to the same place in the layout, so there wasn’t a justification to make
a L/Q distinction here.
With LW3, L-Foo and Q-Foo are two different types, so
> On Apr 8, 2020, at 14:43, John Rose wrote:
>
> I have a proposal for a translation strategy:
>
> 1. Translate casts to inline classes differently from “classic”
> casts. Add an extra step of null hostility. For very low-level
> reasons, I suggest using “ldc X” followed by Class::cast.
>
My two cents on this topic:
Looking back at our previous models, the “identity” marker and the “inline”
marker
served two different and well identified purposes.
The “identity” marker signals that identity sensitive operations are allowed on
a
given type. This is a marker we absolutely need
:08, Frederic Parain wrote:
>
> Hi,
>
> This is a good question.
>
> The ReferenceType descriptor was added to make the distinction between the
> two VM-level
> type sharing the same class name. The CONSTANT_Class_info is used by the
> following bytecodes:
>
Hi,
This is a good question.
The ReferenceType descriptor was added to make the distinction between the two
VM-level
type sharing the same class name. The CONSTANT_Class_info is used by the
following bytecodes:
- ldc
- new
- defaultvalue
- anewarray
- multianewarray
- checkcast
-
# Valhalla EG Meeting 20200129
Dan S., Remi, Brian, Dan (IBM), Tobi (IBM)
Brian:
language side implementation:
compiler support to inject InlineObject/IdentityObject super-types at
compilation time
some issues with reflection code assuming type hierarchy
Remi:
This is a follow up on the discussion about static
inline fields and the risk of having a default value
escaping while the inline class is uninitialized (the
problematic scenario being when the class fails to
initialize properly).
This situation already exists today, it is possible
to produce it
Brian,
Thank you for this description of the new model.
See my comments and questions inlined below.
> On Aug 3, 2019, at 12:37, Brian Goetz wrote:
>
> As Remi noted, we had some good discussions at JVMLS this week. Combining
> that with some discussions John and I have been having over
Here’s the basic question: how the JVM should handle the @Contended
annotation with respect to inline classes?
Here’s some thoughts:
First scenario: the @Contended annotation is used within an inline class:
The @Contended annotation aims to solve the problem of false sharing,
but false sharing
On 07/12/2018 02:41 PM, Tobi Ajila wrote:
> I'm looking for reasons that
> this is a *bad* idea, so we can say in the end, "here's exactly why
we had to make
> the loading logic for VTs so tricky"–if we must.
Karen's initial post mentions our two biggest concerns. If there is no
The JVMS has to be modified to cover the initialization of
static value fields. However, the implications of the change
should be evaluated carefully before committing them.
The JVMS10, section 5.4.2 Preparation says:
"Preparation involves creating the static fields for a class or
interface and
ic") to detect the error earlier, such as at verification time,
> so that a broken program can be detected before it starts to run.
>
> Also, some operations may be contextual, to support backward
> compatibility. Thus, `checkcast` may need to consult the local
> classfile abou
Here’s an update of the JVMS draft:
http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-4.pdf
with the following changes:
* Renamed ACC_NON_NULLABLE with ACC_FLATTENABLE
* Removed restriction that ACC_FLATTENABLE cannot be used on static fields
* Added rules about circularity
rden for the language (because the
purpose
of the flag is to enable some implementation optimizations), so we proposed
to simply forbid them.
If the language team thinks there’s more value in allowing ACC_NON_NULLABLE, we
can revisit the current choice.
Fred
>
>
>> On Jan 31, 2018, at 11:
Here’s a draft of the JVMS proposing a way to implement the L-world value types,
with support for value-based classes migration to value classes (essentially,
support
for nullability):
http://cr.openjdk.java.net/~fparain/L-world/L-World-JVMS-3.pdf
The assumptions and key properties are listed
17 matches
Mail list logo
