Draft LW2 spec

[Karen Kinnear]

Dan,

Many thanks for putting out a draft JVMS for LW2. 
Folks - if you could be explicit in review comments whether they are relevant to LW2
or to post-LW2, e.g. design discussions, that would help.

LW2 comments:

1. Versioning
Thank you for asking.
For LW10, we plan to use preview versioning. For LW2, we just use JDK13 cfv 57

2. 2.4 Reference Types and Values
Bullet defining Array component type
"the element type of a multi-dimensional array is the element type of its component type"
- it is no longer clear that the element type is not the next dimension down, but the
final one that is not itself an array
3. 4.4.1 The CONSTANT_Class_info Strtucture
"In a class file whose version number is not 57.65535, the name_index item must not be a field descriptor of the form NullableClassType or NullFreeClassType."

Actually, since NullableClassType replaced ClassType - isn't it just NullFreeClassType that is not ok?

4. 4.6. Methods
name_index
"The value of the name_index item must be a valid index into the constant_pool table. The constant_pool entry at that index must be a CONSTANT_Utf8_info structure (4.4.7) representing either a valid unqualified name denoting a method (4.2.2), or (if this method is in a class an identity class or the Object class rather than an inline class or an interface) the special method name <init>, or the special method name <clinit>."

— LW2 was changed: now have <init> for inline classes. We also have <clinit>.

5a. 5.4.3.1 Class, Interface and Reference Type Resolution
Any attempt to resolve a reference to a null-free inline type, that resolves to a non-inline type,
throws an ICCE at resolution time.

For example, this is used by 6.5 defaultvalue.

I would assume you want to put this in 5.4.3.1, but you could put this in 6.5 defaultvalue.
The implementation puts this in 5.4.3.1 equivalent. 

5b. 4.9.1. Static Constraints
"Every defaultvalue instruction must reference a constant pool entry of kind CONSTANT_Class that represents a null-free class type.”

In anticipation of evolution of defaultvalue to handle null-default inline types, and possibly
to handle nullable inline types, and in an effort to not add additional eager loading for
the verifier, for LW2, we removed the verifier checks for defaultvalue enforcing a null-free class type and moved the check to runtime.and new bytecodes relative to null-free and inline classes.
6. 5.4.2. Preparation (discussion topic for EG)

Part I: Method descriptors:
JVMS LW2 draft specifies that the declared method ptypes marked as null-free are loaded
as part of preparation, including throwing ICCE if not an inline class.

We have had previous discussions with IBM - I think we want some verbiage to allow eager or
lazy resolution of method ptypes which are null-free inline types.

Hotspot needs to load these as part of linking (we can discuss if this is part of preparation or not later)
IBM wants to lazily load at first invocation

We all agree on ICCE for a mismatch here.

Part II. Field Descriptors: Instance Fields
This has to be performed at load time/class definition time - needed for layout.
  - Not at preparation time - that is too late.

I believe we do agree with ICCE and risk of ClassCircularityError if “flattenable”.

Part III. Field Descriptors: Static Fields

For LW2, for static fields, we do the same exercise as we do for instance fields,
with the same risk of ICCE and ClassCircularityError.

See below for potential post-LW2 static field open issue.

7. putfield:
Needs updating - now that inline classes support <init> - putfield is
not supposed to modify inline class instance fields, even during <init>
(being a final field is not sufficient to stop that) - so need IAE
if resolved field is a field of an inline class.
We don't want verifier to catch since this should apply to both LPoint; and QPoint;

post-LW2, design discussion comments:

1. 6.5. monitorenter
What is the Design discussion proposing?
Would love a solution for this - have not found one that is satisfactory.

Design discussion: we might wish, instead, to support inline class instances by associating a monitor with each unique field-value vector. In that approach, two references have the same monitor iff they are acmpeq.
Further discussion may be warranted on the choice of exception type to throw.

Karen’s concern - about accidental sharing of the same monitor
-in the field surprise bugs - hard to reproduce - timing based
- e.g. I try to lock but you are holding the lock (but we are running completely independent code)
  e.g. overlap for wait and notify (customers do not always check conditions for notify)

2. 5.4.2 Preparation
Post-LW2 we need to have a discussion on how to handle static fields that are inline types.
There are challenges with ClassCircularityIssues even though we have agreed that in practice
we don’t actually want to flatten static null-free inline classes. There are also issues
with timing of default value creation relative to class load/class initialization/visibility
of an instance on which operations can happen, since the class initialization barrier
includes new, defaultvalue/anewarray/multianewarray which allows other bytecodes operating on instances to not have an initialization barrier.
Frederic has been studying possible ways to deal with issues that occur due to examples such as:
example 1: class MyValue: static MyValue; // the degenerate case
example 2: class A: static B sb; class B: static A sa;

thanks,
Karen

> On Jun 18, 2019, at 7:56 PM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
>> On Jun 13, 2019, at 2:57 PM, Dan Smith <daniel.smith at oracle.com <mailto:daniel.smith at oracle.com>> wrote:
>> 
>> Here's a first look at a preview-feature-quality spec for values^H^H^H^H^H^Hinline classes.
>> 
>> http://cr.openjdk.java.net/~dlsmith/inline-classes/specs/jvms-inline-classes.html <http://cr.openjdk.java.net/~dlsmith/inline-classes/specs/jvms-inline-classes.html>
> I've done some tidying up of my cr folder. Please just use this URL now, which redirects to the latest:
> 
> http://cr.openjdk.java.net/~dlsmith/inline-classes <http://cr.openjdk.java.net/~dlsmith/inline-classes>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/attachments/20190620/9c7d092b/attachment-0001.html>