From dsimms at openjdk.org  Tue Nov  1 15:01:26 2022
From: dsimms at openjdk.org (David Simms)
Date: Tue, 1 Nov 2022 15:01:26 GMT
Subject: [lworld] RFR: 8296172: [lworld]
 vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage007/TestDescription.java
 fails with "primitive" keyword
Message-ID: <Wfu2EDil_KnZaWscWDB8_hTJIXT2ytBgHEy8SwznyW4=.d30edd52-9a2d-4bf0-ab40-91f4f04c8bd9@github.com>

Use "value object"

-------------

Commit messages:
 - 8296172: [lworld] vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage007/TestDescription.java fails with "primitive" keyword

Changes: https://git.openjdk.org/valhalla/pull/803/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=803&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296172
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/valhalla/pull/803.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/803/head:pull/803

PR: https://git.openjdk.org/valhalla/pull/803

From dsimms at openjdk.org  Tue Nov  1 15:04:50 2022
From: dsimms at openjdk.org (David Simms)
Date: Tue, 1 Nov 2022 15:04:50 GMT
Subject: [lworld] Integrated: 8296172: [lworld]
 vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage007/TestDescription.java
 fails with "primitive" keyword
In-Reply-To: <Wfu2EDil_KnZaWscWDB8_hTJIXT2ytBgHEy8SwznyW4=.d30edd52-9a2d-4bf0-ab40-91f4f04c8bd9@github.com>
References: <Wfu2EDil_KnZaWscWDB8_hTJIXT2ytBgHEy8SwznyW4=.d30edd52-9a2d-4bf0-ab40-91f4f04c8bd9@github.com>
Message-ID: <8qOzMmEdOTc_eHszqFtxG_AGrQkCWNecuGWBzIfIeiM=.8f8be019-2094-40be-99a7-3ff2cccb001c@github.com>

On Tue, 1 Nov 2022 14:55:32 GMT, David Simms <dsimms at openjdk.org> wrote:

> Use "value object"

This pull request has now been integrated.

Changeset: 3d42cca6
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3d42cca60478a6470620746a1e33eaff639570c8
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8296172: [lworld] vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage007/TestDescription.java fails with "primitive" keyword

-------------

PR: https://git.openjdk.org/valhalla/pull/803

From mchung at openjdk.org  Tue Nov  1 17:29:00 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 1 Nov 2022 17:29:00 GMT
Subject: [lworld] RFR: JDK-8293321: [lworld] substitutability test shall
 support value class with cyclic membership [v3]
In-Reply-To: <RriOj-D3CfiAqQyRPBFO3BmUisDkNsGGOeRAiwHkhVk=.3376d401-14cf-4826-a316-bda56a4349de@github.com>
References: <RriOj-D3CfiAqQyRPBFO3BmUisDkNsGGOeRAiwHkhVk=.3376d401-14cf-4826-a316-bda56a4349de@github.com>
Message-ID: <0ZSw88XWLRJ6yl45PI3MRTpPNa5FCWEnXgP4_ln3-k4=.8b4917be-993e-47bf-abcf-3df7ff53b691@github.com>

> L-type allows cycles. `acmp` shall support value classes with cyclic membership.  This PR adds the support in the Java implementation of `acmp` (i.e. `ValueObjectMethods::isSubstitutable`). 
> 
> This patch includes [John's first cut to make a Y combinator method handle](https://github.com/openjdk/jdk/pull/10155) to enable a method handle to call itself recursively.    PR 10155 is adequate for internal use for now.  A separate RFE will follow to define such an API.
> 
> A separate issue [JDK-8296056](https://bugs.openjdk.org/browse/JDK-8296056) tracks the C2 `acmp` support.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  ignore test to run with C1

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/802/files
  - new: https://git.openjdk.org/valhalla/pull/802/files/8b1e5508..67148fad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=802&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=802&range=01-02

  Stats: 14 lines in 2 files changed: 7 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/valhalla/pull/802.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/802/head:pull/802

PR: https://git.openjdk.org/valhalla/pull/802

From mchung at openjdk.org  Tue Nov  1 19:28:14 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 1 Nov 2022 19:28:14 GMT
Subject: [lworld] Integrated: JDK-8293321: [lworld] substitutability test shall
 support value class with cyclic membership
In-Reply-To: <RriOj-D3CfiAqQyRPBFO3BmUisDkNsGGOeRAiwHkhVk=.3376d401-14cf-4826-a316-bda56a4349de@github.com>
References: <RriOj-D3CfiAqQyRPBFO3BmUisDkNsGGOeRAiwHkhVk=.3376d401-14cf-4826-a316-bda56a4349de@github.com>
Message-ID: <WmNXzXs-2TY34fGoQbJ7sESBFe54ql2lsfBdC_z7v34=.90277bbd-bede-4171-88bc-b0b07f140f2e@github.com>

On Fri, 28 Oct 2022 17:15:19 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> L-type allows cycles. `acmp` shall support value classes with cyclic membership.  This PR adds the support in the Java implementation of `acmp` (i.e. `ValueObjectMethods::isSubstitutable`). 
> 
> This patch includes [John's first cut to make a Y combinator method handle](https://github.com/openjdk/jdk/pull/10155) to enable a method handle to call itself recursively.    PR 10155 is adequate for internal use for now.  A separate RFE will follow to define such an API.
> 
> A separate issue [JDK-8296056](https://bugs.openjdk.org/browse/JDK-8296056) tracks the C2 `acmp` support.

This pull request has now been integrated.

Changeset: 0ff3973c
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0ff3973c6105ae8f7b3709caa452ceed8df8f885
Stats:     769 lines in 3 files changed: 743 ins; 4 del; 22 mod

8293321: [lworld] substitutability test shall support value class with cyclic membership

-------------

PR: https://git.openjdk.org/valhalla/pull/802

From mchung at openjdk.org  Fri Nov  4 21:01:05 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 4 Nov 2022 21:01:05 GMT
Subject: [lworld] RFR: 8296423: [lworld] add VarHandle tests for value classes
Message-ID: <JxbR33b2bn5NAJ3ewvzMrzXiE6DUsWlY6Mpk1SDp1Pg=.ab6008ee-915e-42ed-a8b8-cde5aa4b4733@github.com>

Add VarHandle tests for value class.   This fixes a bug in Unsafe::compareAndSet support.   This also cleans up test/jdk/java/lang/invoke/VarHandles tests such that it only extends the tests for value class and primitive class.  The test cases  for accessing fields declared in a value class or a primitive class are covered by tests in test/jdk/valhalla/valuetypes.

-------------

Commit messages:
 - clean up tests
 - Add VarHandle tests for value class and fix issues

Changes: https://git.openjdk.org/valhalla/pull/804/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=804&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296423
  Stats: 5103 lines in 35 files changed: 4290 ins; 662 del; 151 mod
  Patch: https://git.openjdk.org/valhalla/pull/804.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/804/head:pull/804

PR: https://git.openjdk.org/valhalla/pull/804

From mchung at openjdk.org  Fri Nov  4 21:15:33 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 4 Nov 2022 21:15:33 GMT
Subject: [lworld] Integrated: 8296423: [lworld] add VarHandle tests for value
 classes
In-Reply-To: <JxbR33b2bn5NAJ3ewvzMrzXiE6DUsWlY6Mpk1SDp1Pg=.ab6008ee-915e-42ed-a8b8-cde5aa4b4733@github.com>
References: <JxbR33b2bn5NAJ3ewvzMrzXiE6DUsWlY6Mpk1SDp1Pg=.ab6008ee-915e-42ed-a8b8-cde5aa4b4733@github.com>
Message-ID: <3tvYB3J1pzl7MZsTtMBJWmxOcs9q0JM1Vo8-LVAi9t0=.9b0e7650-8f80-4d33-9958-85c6688e4d98@github.com>

On Fri, 4 Nov 2022 20:54:31 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Add VarHandle tests for value class.   This fixes a bug in Unsafe::compareAndSet support.   This also cleans up test/jdk/java/lang/invoke/VarHandles tests such that it only extends the tests for value class and primitive class.  The test cases  for accessing fields declared in a value class or a primitive class are covered by tests in test/jdk/valhalla/valuetypes.

This pull request has now been integrated.

Changeset: dfaaafc2
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/dfaaafc2e8540be57789412d5932a2d31b1ccc30
Stats:     5103 lines in 35 files changed: 4290 ins; 662 del; 151 mod

8296423: [lworld] add VarHandle tests for value classes

-------------

PR: https://git.openjdk.org/valhalla/pull/804

From mchung at openjdk.org  Mon Nov  7 19:16:44 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 7 Nov 2022 19:16:44 GMT
Subject: [lworld] RFR: 8296491: Implement Object::hashcode for
 recursively-typed values
Message-ID: <GPY6lfazlWSIYmglU93c3jkeCFvhfM6avm2NmrY_t7Y=.9e919f1f-30e6-41aa-a9d6-2805c623c077@github.com>

This is a follow-up of JDK-8293321 to complete the implementation for recursively-typed values.

-------------

Commit messages:
 - Implement Object::hashcode for recursively-typed values

Changes: https://git.openjdk.org/valhalla/pull/805/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=805&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296491
  Stats: 280 lines in 2 files changed: 203 ins; 35 del; 42 mod
  Patch: https://git.openjdk.org/valhalla/pull/805.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/805/head:pull/805

PR: https://git.openjdk.org/valhalla/pull/805

From mchung at openjdk.org  Mon Nov  7 22:56:50 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 7 Nov 2022 22:56:50 GMT
Subject: [lworld] Integrated: 8296491: [lworld] implement Object::hashCode for
 recursively-typed values
In-Reply-To: <GPY6lfazlWSIYmglU93c3jkeCFvhfM6avm2NmrY_t7Y=.9e919f1f-30e6-41aa-a9d6-2805c623c077@github.com>
References: <GPY6lfazlWSIYmglU93c3jkeCFvhfM6avm2NmrY_t7Y=.9e919f1f-30e6-41aa-a9d6-2805c623c077@github.com>
Message-ID: <jPzUyZbUffxi_XwBbLMj0neAHG230xsl3f9Q6GMnkTI=.fa859cde-7762-41ed-aec6-c57aecd62de8@github.com>

On Mon, 7 Nov 2022 19:09:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This is a follow-up of JDK-8293321 to complete the implementation for recursively-typed values.

This pull request has now been integrated.

Changeset: 8346a822
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8346a82215c607a59f7087e8c226ffd5847cbce9
Stats:     280 lines in 2 files changed: 203 ins; 35 del; 42 mod

8296491: [lworld] implement Object::hashCode for recursively-typed values

-------------

PR: https://git.openjdk.org/valhalla/pull/805

From jbhateja at openjdk.org  Thu Nov 10 09:03:36 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 10 Nov 2022 09:03:36 GMT
Subject: [lworld+vector] RFR: 8296767: Support multi-field based vector
 classes.
Message-ID: <ab8dGbiEaSMgrgvBaRUboTPt3YLWN5C2Pqw-Fm_rN_c=.2e39aa53-03a8-444b-8b6d-58a40e463b54@github.com>

Initial Java side changes for treating vector as a value class based on suggestions from John Rose[1].

Summary of changes:
1) Re-define existing vector class hierarchy to use generic multi-field[2] based payloads of bit sizes 64, 128, 256 and 512.
2) Concrete vectors are now value classes encapsulating primitive class instances as payload.
3) Update fallback implementation to read/write from multi-field payload using Unsafe APIs.
4) New VM symbol definitions for generic payloads.

All existing JTREG tests are passing with -Xint option.

C2 side change, runtime support for vector object reconstruction, shuffle and masks handling is still based on existing flow
and will be handled in subsequent patch.

MAX species queries target supported max vector size, since multi-field annotation does not accept variable argument hence MAX species based vector class generation has been disabled currently.

[1] http://cr.openjdk.java.net/~jrose/values/multi-field.html
[2] https://github.com/fparain/valhalla/tree/multifield

-------------

Commit messages:
 - 8296767: Fix white spaces.
 - 8296767: Fix white spaces.
 - 8296767: Support multi-field based vector classes.

Changes: https://git.openjdk.org/valhalla/pull/806/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=806&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296767
  Stats: 9870 lines in 53 files changed: 1926 ins; 5601 del; 2343 mod
  Patch: https://git.openjdk.org/valhalla/pull/806.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/806/head:pull/806

PR: https://git.openjdk.org/valhalla/pull/806

From redio.development at gmail.com  Sat Nov 12 09:13:43 2022
From: redio.development at gmail.com (redio.development at gmail.com)
Date: Sat, 12 Nov 2022 10:13:43 +0100
Subject: Providing runtime type information without changing type erasure 
Message-ID: <00a301d8f677$10268290$307387b0$@gmail.com>

I was once again writing some generic Java class and suddenly I stand there
again, I could not get the type of T.

I'm sure this scenario sound familiar to every Java developer out there.

If you first stumble across this problem type erasure comes up as the
culprit: "Type T is not there at runtime it is replaced with Object"

There are many solutions to this problem some hacky some require braking
change to the generic system.

Now my idea was why don't we trace back the types at compile time? I mean
every generic class is constructed somewhere in 6 possible ways:

1.	Foo<String> foo = new Foo<>();
2.	Foo<T> foo2 = new Foo<>();
3.	Foo foo3 = new Foo();
4.	Foo<?> foo4 = new Foo<>(); 
5.	Foo<? extends String> foo5 = new Foo<>();
6.	Foo<? super String> foo6 = new Foo<>();

In case 1 we are already at our destination. The code the compiler gets
contains the information we want. Why don't we attach the type written in
plain sight to the generic constructor?

Like an implicit Foo<String> foo = new Foo<>(java.lang.String.class); (which
explicitly is a current way of solving this. Which is in my opinion pretty
ugly.)

It would be syntactic sugar for the syntax above which spares the developers
of repeating themselves. (just like <> does)

If the compiler would just use the information he is erasing to fill it into
the constructor. The only thing changing would be that the constructor would
take 1 additional hidden argument and since the argument is filled at
compile time it would not brake any code.

In case 2 we are in some generic context like a nested class or a generic
method. In both cases the actual type of T will be available. Such
situations might require multiple passes to solve all dependencies. Then we
can proceed like in 1.

In case 3 we are dealing with legacy code and the type is always object.
(Foo foo = new Foo(java.lang.Object))

In case 4 we are dealing with an open type bound. The type is not
constrained so we can only assume Object (Foo<?> foo = new
Foo<>(java.lang.Object))

In case 5 we have a upper constrained type bound. We can assume any Object
passing that bound Is a subclass of String (Foo<? extends String> foo = new
Foo<>(java.lang.String))

In case 6 we have a lower constrained type bound. The Object passing this
type bound could be Object. (Foo<? super String> foo = new
Foo<>(java.lang.Object))

 

We would store the types at constructor or Method Invocation as arguments
and then map them to the accessor T.class. This would allow type checking of
T at runtime by tracing the real type at compile time.

Since the type of T.class would be Class<T> or Class<?> we would not need to
create a method or a class for each different version of the method or class
like other languages do. 

I'm not quite sure how reflection is implemented but I'm sure there is a
central invocation where the compiler could add the T.class argument. Of
course we would need a way for reflection to specify the type T for this to
work. We would simply need a method that is designed for generic classes
like "<T> Constructor<T> getGenericConstructor(Class<?>[]
typeParameterTypes, Class<?>. parameterTypes)" (could have a better
signature).

If the "getConstructor" is used on a generic class there would be a warning
and the parameters would be set to Object (resulting in a raw object like
any Objects generated by reflection currently are).

 

Risks:

It would require the addition of n fields to any generic class or method
where n stands for the number of generic arguments, which could result in
performance and memory issues when adding this many new fields to the heap
and stack. This issue could be reduced by only adding this mechanism when
T.class or instanceof T are actually used in the context and would be skiped
if the field is not used in the first place. Resulting in unchanged field
count in all class files if the feature is used nowhere.

Another rist would be the obvious change in class files, since the hidden
arguments need to be stored at compile time near the invoke of the
method/constructor.

 

This is just an idea based on my knowledge on generics in java. 

Please feel free to correct any misconceptions in this idea and tell me if I
missed something.

 

Great regards

RedIODev

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20221112/3ae54275/attachment-0001.htm>

From rriggs at openjdk.org  Mon Nov 14 18:46:40 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 14 Nov 2022 18:46:40 GMT
Subject: [lworld] RFR: 8296711: [lworld] identity/value javadoc cleanup
Message-ID: <h9rpy3ECm88y8LhU9ewRPwiM7eBuYqyFvxY0wTHR4Ek=.6fb604bb-11ef-4cd4-aae1-88687b2fdcad@github.com>

Clarify the java doc descriptions in java.lang.ref classes to say that References can only be created to identity objects.

-------------

Commit messages:
 - 8296711: [lworld] identity/value javadoc cleanup

Changes: https://git.openjdk.org/valhalla/pull/807/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=807&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296711
  Stats: 16 lines in 4 files changed: 5 ins; 6 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/807.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/807/head:pull/807

PR: https://git.openjdk.org/valhalla/pull/807

From rriggs at openjdk.org  Mon Nov 14 21:19:22 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 14 Nov 2022 21:19:22 GMT
Subject: [lworld] RFR: 8296950: [lworld] AccessFlags should be specific to
 class file version.
Message-ID: <39YntreEgkmZr5fVA84OCgX62FqbWzUO5_9kWSPXaDk=.7c54f113-109d-4154-8831-5b4a2bd8f391@github.com>

Add java.lang.reflect.AccessFlag.maskToAccessFlags(mask, location, cffv) 
that requests the flags for a specific class file version number.
Update Class.accessFlags() to request the flags for the specific class file format version of the class file.
Update class file format version tests to match.

-------------

Commit messages:
 - 8296950: [lworld] AccessFlags should be specific to class file version.

Changes: https://git.openjdk.org/valhalla/pull/808/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=808&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296950
  Stats: 112 lines in 8 files changed: 95 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/valhalla/pull/808.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/808/head:pull/808

PR: https://git.openjdk.org/valhalla/pull/808

From mchung at openjdk.org  Tue Nov 15 17:46:40 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 15 Nov 2022 17:46:40 GMT
Subject: [lworld] RFR: 8296711: [lworld] identity/value javadoc cleanup
In-Reply-To: <h9rpy3ECm88y8LhU9ewRPwiM7eBuYqyFvxY0wTHR4Ek=.6fb604bb-11ef-4cd4-aae1-88687b2fdcad@github.com>
References: <h9rpy3ECm88y8LhU9ewRPwiM7eBuYqyFvxY0wTHR4Ek=.6fb604bb-11ef-4cd4-aae1-88687b2fdcad@github.com>
Message-ID: <inaRbhsoTRAOFIyBWhMAkfyMi2675CA_A2gOvbQjBVs=.4f0bb25b-ce29-4d2c-81a5-83a475e530f5@github.com>

On Mon, 14 Nov 2022 18:40:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Clarify the java doc descriptions in java.lang.ref classes to say that References can only be created to identity objects.

Marked as reviewed by mchung (Committer).

-------------

PR: https://git.openjdk.org/valhalla/pull/807

From rriggs at openjdk.org  Tue Nov 15 18:40:15 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 15 Nov 2022 18:40:15 GMT
Subject: [lworld] Integrated: 8296711: [lworld] identity/value javadoc cleanup
In-Reply-To: <h9rpy3ECm88y8LhU9ewRPwiM7eBuYqyFvxY0wTHR4Ek=.6fb604bb-11ef-4cd4-aae1-88687b2fdcad@github.com>
References: <h9rpy3ECm88y8LhU9ewRPwiM7eBuYqyFvxY0wTHR4Ek=.6fb604bb-11ef-4cd4-aae1-88687b2fdcad@github.com>
Message-ID: <A8UVTClDBKZB7oBXwGWJ8cK1JA8XSqy0_oC4z32gDLM=.618bf201-8bfe-4159-b44a-eef4e362493e@github.com>

On Mon, 14 Nov 2022 18:40:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Clarify the java doc descriptions in java.lang.ref classes to say that References can only be created to identity objects.

This pull request has now been integrated.

Changeset: d2fe8c59
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/d2fe8c59f9b4b183a443f4abd2c676492a5a491f
Stats:     16 lines in 4 files changed: 5 ins; 6 del; 5 mod

8296711: [lworld] identity/value javadoc cleanup

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/valhalla/pull/807

From dsimms at openjdk.org  Tue Nov 15 19:46:24 2022
From: dsimms at openjdk.org (David Simms)
Date: Tue, 15 Nov 2022 19:46:24 GMT
Subject: [lworld] RFR: Removed bad named test
Message-ID: <ziI-_QP6oOQqGqa6irB2TFtQKpuCrwf8JS7bJ4i5ZPg=.a2ff5602-641e-4c4d-afa0-7909a3d1c7ce@github.com>

Lower case f in field

-------------

Commit messages:
 - Removed bad named test

Changes: https://git.openjdk.org/valhalla/pull/809/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=809&range=00
  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/809.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/809/head:pull/809

PR: https://git.openjdk.org/valhalla/pull/809

From dsimms at openjdk.org  Tue Nov 15 19:48:15 2022
From: dsimms at openjdk.org (David Simms)
Date: Tue, 15 Nov 2022 19:48:15 GMT
Subject: [lworld] Integrated: Removed bad named test
In-Reply-To: <ziI-_QP6oOQqGqa6irB2TFtQKpuCrwf8JS7bJ4i5ZPg=.a2ff5602-641e-4c4d-afa0-7909a3d1c7ce@github.com>
References: <ziI-_QP6oOQqGqa6irB2TFtQKpuCrwf8JS7bJ4i5ZPg=.a2ff5602-641e-4c4d-afa0-7909a3d1c7ce@github.com>
Message-ID: <uzfiIhl91qOb4xlXDsqMgk7AqLZYeui09VTAdAsnQu4=.29a3885d-ac0a-4acf-a630-6349555ffd35@github.com>

On Tue, 15 Nov 2022 19:39:38 GMT, David Simms <dsimms at openjdk.org> wrote:

> Lower case f in field

This pull request has now been integrated.

Changeset: 994e8434
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/994e84343f973c31a308b2975018ea7b1c19ea36
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

Removed bad named test

-------------

PR: https://git.openjdk.org/valhalla/pull/809

From vromero at openjdk.org  Thu Nov 17 11:29:35 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 17 Nov 2022 11:29:35 GMT
Subject: [lworld] RFR: 8297199: [lworld] relocate test folder
Message-ID: <PQM6x8Msg18SVqEVYHIXTwpHkiomerzO1L5Y6VdA5jg=.5876e5ff-0d23-4bcb-bf71-db9b232576dc@github.com>

just a test folder relocation

-------------

Commit messages:
 - 8297199: [lworld] relocate test folder

Changes: https://git.openjdk.org/valhalla/pull/810/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=810&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297199
  Stats: 0 lines in 3 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/810.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/810/head:pull/810

PR: https://git.openjdk.org/valhalla/pull/810

From vromero at openjdk.org  Thu Nov 17 11:31:29 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 17 Nov 2022 11:31:29 GMT
Subject: [lworld] Integrated: 8297199: [lworld] relocate test folder
In-Reply-To: <PQM6x8Msg18SVqEVYHIXTwpHkiomerzO1L5Y6VdA5jg=.5876e5ff-0d23-4bcb-bf71-db9b232576dc@github.com>
References: <PQM6x8Msg18SVqEVYHIXTwpHkiomerzO1L5Y6VdA5jg=.5876e5ff-0d23-4bcb-bf71-db9b232576dc@github.com>
Message-ID: <PtlVFffr8grS2qUHxZQALI8CKhFE9MoZ06ujTX62SyI=.10e67a86-54c5-49b8-85a6-36b3d9d022ad@github.com>

On Thu, 17 Nov 2022 11:22:53 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> just a test folder relocation

This pull request has now been integrated.

Changeset: 02e11831
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/02e118314bd207ed718703e1680349d6e47d3ee1
Stats:     0 lines in 3 files changed: 0 ins; 0 del; 0 mod

8297199: [lworld] relocate test folder

-------------

PR: https://git.openjdk.org/valhalla/pull/810

From vromero at openjdk.org  Fri Nov 18 21:23:32 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 18 Nov 2022 21:23:32 GMT
Subject: [lworld] RFR: 8297207: [lworld] refactor primitive classes tests
Message-ID: <HGfZPrDce6feYL7EmFSZVrdzcXw9olLENvHU1Xhf5BM=.6ed0e5dd-f644-430d-b6c8-532a995bc05d@github.com>

refactoring primitive classes tests, consolidating compilation tests etc

-------------

Commit messages:
 - additional changes
 - 8297207: [lworld] refactor primitive classes tests

Changes: https://git.openjdk.org/valhalla/pull/811/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=811&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8297207
  Stats: 555 lines in 8 files changed: 325 ins; 230 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/811.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/811/head:pull/811

PR: https://git.openjdk.org/valhalla/pull/811

From vromero at openjdk.org  Sat Nov 19 00:51:34 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 19 Nov 2022 00:51:34 GMT
Subject: [lworld] RFR: 8297207: [lworld] refactor primitive classes tests
 [v2]
In-Reply-To: <HGfZPrDce6feYL7EmFSZVrdzcXw9olLENvHU1Xhf5BM=.6ed0e5dd-f644-430d-b6c8-532a995bc05d@github.com>
References: <HGfZPrDce6feYL7EmFSZVrdzcXw9olLENvHU1Xhf5BM=.6ed0e5dd-f644-430d-b6c8-532a995bc05d@github.com>
Message-ID: <H6CuYViE_roEiBcBX1SgnLpOVp0I36ssIt6bzCHo0KE=.d6109dac-fbd8-48c0-bfab-3253794d50bf@github.com>

> refactoring primitive classes tests, consolidating compilation tests etc

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  integrating more tests

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/811/files
  - new: https://git.openjdk.org/valhalla/pull/811/files/aa56634b..576f6854

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=811&range=01
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=811&range=00-01

  Stats: 185 lines in 9 files changed: 89 ins; 96 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/811.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/811/head:pull/811

PR: https://git.openjdk.org/valhalla/pull/811

From vromero at openjdk.org  Sun Nov 20 01:07:03 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 20 Nov 2022 01:07:03 GMT
Subject: [lworld] RFR: 8297207: [lworld] refactor primitive classes tests
 [v3]
In-Reply-To: <HGfZPrDce6feYL7EmFSZVrdzcXw9olLENvHU1Xhf5BM=.6ed0e5dd-f644-430d-b6c8-532a995bc05d@github.com>
References: <HGfZPrDce6feYL7EmFSZVrdzcXw9olLENvHU1Xhf5BM=.6ed0e5dd-f644-430d-b6c8-532a995bc05d@github.com>
Message-ID: <YS_HgRBNPboE1_PhmjDLjEP52ixMgfXKHSrCN84ZxfQ=.a2e1977d-c6bc-40d7-846a-d123f6e6d491@github.com>

> refactoring primitive classes tests, consolidating compilation tests etc

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  integrating more tests

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/811/files
  - new: https://git.openjdk.org/valhalla/pull/811/files/576f6854..3006e388

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=811&range=02
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=811&range=01-02

  Stats: 588 lines in 23 files changed: 213 ins; 375 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/811.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/811/head:pull/811

PR: https://git.openjdk.org/valhalla/pull/811

From vromero at openjdk.org  Sun Nov 20 01:34:55 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 20 Nov 2022 01:34:55 GMT
Subject: [lworld] RFR: 8297207: [lworld] refactor primitive classes tests
 [v4]
In-Reply-To: <HGfZPrDce6feYL7EmFSZVrdzcXw9olLENvHU1Xhf5BM=.6ed0e5dd-f644-430d-b6c8-532a995bc05d@github.com>
References: <HGfZPrDce6feYL7EmFSZVrdzcXw9olLENvHU1Xhf5BM=.6ed0e5dd-f644-430d-b6c8-532a995bc05d@github.com>
Message-ID: <m4s0ofje5Jid8jDiTAL1I-9agP8Dos3oacEbOQ85vEY=.2a1f0de3-6fa5-4b3a-82a6-3041282682f4@github.com>

> refactoring primitive classes tests, consolidating compilation tests etc

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8297207' of https://github.com/vicente-romero-oracle/valhalla into JDK-8297207
 - integrating more tests

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/811/files
  - new: https://git.openjdk.org/valhalla/pull/811/files/3006e388..1d4d77d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=811&range=03
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=811&range=02-03

  Stats: 64 lines in 5 files changed: 15 ins; 49 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/811.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/811/head:pull/811

PR: https://git.openjdk.org/valhalla/pull/811

From rriggs at openjdk.org  Mon Nov 21 17:47:07 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 21 Nov 2022 17:47:07 GMT
Subject: [lworld] RFR: 8286824: [valhalla] WeakHashMap for value classes
 [v2]
In-Reply-To: <GEqB28hcKn7HCPs87eaFuYInmGDjTFrL_HCvQRoOJQg=.93972f1a-006a-4569-b458-6712eff21935@github.com>
References: <GEqB28hcKn7HCPs87eaFuYInmGDjTFrL_HCvQRoOJQg=.93972f1a-006a-4569-b458-6712eff21935@github.com>
Message-ID: <VSD8kVCHZUl3Z3oHG0AxxOlAxdd7uGjp5Lzrm8zXMq4=.e6e22469-6bec-414f-a9da-6814954b3869@github.com>

> WeakHashMap uses WeakReference for keys, allowing it to retain only keys and values that are strongly referenced elsewhere.
> 
> The behavior of WeakReference (or any Reference class) is not defined for value objects.
> 
> Four (4) behaviors are proposed for WeakHashMap to give the developer a choice:
>  - SOFT - Keys that are value objects are retained until memory pressure clears soft references; then the keys that are value objects are removed automatically
>  - STRONG - Keys are value objects are retained until they are explicitly removed
>  - THROW - Keys that are value objects can not be put into the map; UnsupportedOperationException is thrown
>  - DISCARD - Keys that are value objects are silently discarded; as if they were removed immediately without being visible
> 
> The default is SOFT - key/values are removed when there is memory pressure.
> Entries will be removed automatically at some point, though less deterministically than with WeakReferences.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'lworld' into 8286824-weakhashmap
 - Fix bug when key is null.
   Change to throw IdentityException from WeakHashmap when
   a value object is put and the ValuePolicy is throw.
 - Merge branch 'lworld' into 8286824-weakhashmap
 - Merge branch 'lworld' into 8286824-weakhashmap
 - review comment updates
 - Merge
 - javadoc cleanup
 - replace newIdentity with 'new Object()'
 - fix NPE
 - Merge branch 'lworld' into 8286824-weakhashmap
 - ... and 3 more: https://git.openjdk.org/valhalla/compare/02e11831...bba71353

-------------

Changes: https://git.openjdk.org/valhalla/pull/718/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=718&range=01
  Stats: 466 lines in 3 files changed: 460 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/718.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/718/head:pull/718

PR: https://git.openjdk.org/valhalla/pull/718

From vromero at openjdk.org  Tue Nov 22 16:37:56 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 22 Nov 2022 16:37:56 GMT
Subject: [lworld] RFR: 8297207: [lworld] refactor primitive classes tests
 [v5]
In-Reply-To: <HGfZPrDce6feYL7EmFSZVrdzcXw9olLENvHU1Xhf5BM=.6ed0e5dd-f644-430d-b6c8-532a995bc05d@github.com>
References: <HGfZPrDce6feYL7EmFSZVrdzcXw9olLENvHU1Xhf5BM=.6ed0e5dd-f644-430d-b6c8-532a995bc05d@github.com>
Message-ID: <y1UUmqRTy_U1GEEe1TlF0yvVH-oe4TzynkSb6uFzthk=.2708fa34-baa6-418d-ba9b-50610a01e1cf@github.com>

> refactoring primitive classes tests, consolidating compilation tests etc

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  additional changes

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/811/files
  - new: https://git.openjdk.org/valhalla/pull/811/files/1d4d77d5..ff004449

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=811&range=04
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=811&range=03-04

  Stats: 820 lines in 17 files changed: 524 ins; 296 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/811.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/811/head:pull/811

PR: https://git.openjdk.org/valhalla/pull/811

From psandoz at openjdk.org  Wed Nov 23 22:41:05 2022
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 23 Nov 2022 22:41:05 GMT
Subject: [lworld+vector] RFR: 8296767: Support multi-field based vector
 classes.
In-Reply-To: <ab8dGbiEaSMgrgvBaRUboTPt3YLWN5C2Pqw-Fm_rN_c=.2e39aa53-03a8-444b-8b6d-58a40e463b54@github.com>
References: <ab8dGbiEaSMgrgvBaRUboTPt3YLWN5C2Pqw-Fm_rN_c=.2e39aa53-03a8-444b-8b6d-58a40e463b54@github.com>
Message-ID: <6U1RmRP86EMdCQUau9MWgi4hkYKA7lcHVjE9XCmFWjk=.5e0abdea-e489-48a6-9cb1-ba1677a9bf25@github.com>

On Thu, 10 Nov 2022 08:15:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Initial Java side changes for treating vector as a value class based on suggestions from John Rose[1].
> 
> Summary of changes:
> 1) Re-define existing vector class hierarchy to use generic multi-field[2] based payloads of bit sizes 64, 128, 256 and 512.
> 2) Concrete vectors are now value classes encapsulating primitive class instances as payload.
> 3) Update fallback implementation to read/write from multi-field payload using Unsafe APIs.
> 4) New VM symbol definitions for generic payloads.
> 
> All existing JTREG tests are passing with -Xint option.
> 
> C2 side change, runtime support for vector object reconstruction, shuffle and masks handling is still based on existing flow
> and will be handled in subsequent patch.
> 
> MAX species queries target supported max vector size, since multi-field annotation does not accept variable argument hence MAX species based vector class generation has been disabled currently.
> 
> [1] http://cr.openjdk.java.net/~jrose/values/multi-field.html
> [2] https://github.com/fparain/valhalla/tree/multifield

I would recommend if you can to avoid unnecessary renaming such as uOp -> uOpMF, thereby making it easier to read/review as we go.

Something to do in a further iteration: we should be able to place the Unsafe access methods within static methods of the vector payload classe and avoid the use in the vector implementations.

make/common/JavaCompilation.gmk line 272:

> 270:   PARANOIA_FLAGS := -implicit:none -Xprefer:source -XDignore.symbol.file=true -encoding ascii
> 271: 
> 272:   $1_FLAGS += -g -XDenablePrimitiveClasses -Xlint:all $$($1_TARGET_RELEASE) $$(PARANOIA_FLAGS) $$(JAVA_WARNINGS_ARE_ERRORS)

Can you modify `make/modules/java.base/Java.gmk` and possibly `make/modules/jdk.incubator.vector/Java.gmk` instead to limit the scope?

src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 205:

> 203:         }
> 204: 
> 205:         public static VectorPayloadMF createVectPayloadInstanceB(int elemSize, int length, byte [] init) {

Suggestion:

        public static VectorPayloadMF createVectPayloadInstanceB(int elemSize, int length, byte[] init) {

Same for others.

src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 211:

> 209:             for (int i = 0; i < length; i++) {
> 210:                 Unsafe.getUnsafe().putByte(obj, start_offset + i * Byte.BYTES, init[i]);
> 211:             }

It may be possibly to unify all these create methods using `Unsafe.copyMemory`

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/gen-src.sh line 60:

> 58:   Type="$(tr '[:lower:]' '[:upper:]' <<< ${type:0:1})${type:1}"
> 59:   TYPE="$(tr '[:lower:]' '[:upper:]' <<< ${type})"
> 60:   Boxinitials="$(tr '[:lower:]' '[:upper:]' <<< ${type:0:1})"

No need for this. Just use the full box type name.

test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java line 27:

> 25:  * @test
> 26:  * @modules jdk.incubator.vector
> 27:  * @run testng/othervm -ea -esa -Xbatch ShortMaxVectorTests

No need for this change and in the other max vector tests?

test/jdk/jdk/incubator/vector/gen-tests.sh line 136:

> 134:   Log true "${Type}:"
> 135: 
> 136:   for bits in 64 128 256 512

No need for this change?

-------------

PR: https://git.openjdk.org/valhalla/pull/806

From jbhateja at openjdk.org  Wed Nov 23 23:49:27 2022
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 23 Nov 2022 23:49:27 GMT
Subject: [lworld+vector] Integrated: 8296767: Support multi-field based vector
 classes.
In-Reply-To: <ab8dGbiEaSMgrgvBaRUboTPt3YLWN5C2Pqw-Fm_rN_c=.2e39aa53-03a8-444b-8b6d-58a40e463b54@github.com>
References: <ab8dGbiEaSMgrgvBaRUboTPt3YLWN5C2Pqw-Fm_rN_c=.2e39aa53-03a8-444b-8b6d-58a40e463b54@github.com>
Message-ID: <e3Qdzb5SbbqPtq8X5GoTumy3v4LVHIgQhJBnqLaBwx8=.1ec34284-f93f-4d67-9778-dfbfd2a1f96d@github.com>

On Thu, 10 Nov 2022 08:15:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Initial Java side changes for treating vector as a value class based on suggestions from John Rose[1].
> 
> Summary of changes:
> 1) Re-define existing vector class hierarchy to use generic multi-field[2] based payloads of bit sizes 64, 128, 256 and 512.
> 2) Concrete vectors are now value classes encapsulating primitive class instances as payload.
> 3) Update fallback implementation to read/write from multi-field payload using Unsafe APIs.
> 4) New VM symbol definitions for generic payloads.
> 
> All existing JTREG tests are passing with -Xint option.
> 
> C2 side change, runtime support for vector object reconstruction, shuffle and masks handling is still based on existing flow
> and will be handled in subsequent patch.
> 
> MAX species queries target supported max vector size, since multi-field annotation does not accept variable argument hence MAX species based vector class generation has been disabled currently.
> 
> [1] http://cr.openjdk.java.net/~jrose/values/multi-field.html
> [2] https://github.com/fparain/valhalla/tree/multifield

This pull request has now been integrated.

Changeset: 8159184e
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Committer: Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/8159184e95f67bb5ea4d3754bfcf7ab7a25a9803
Stats:     9870 lines in 53 files changed: 1926 ins; 5601 del; 2343 mod

8296767: Support multi-field based vector classes.

-------------

PR: https://git.openjdk.org/valhalla/pull/806

From zjx001202 at gmail.com  Mon Nov 28 10:10:18 2022
From: zjx001202 at gmail.com (Glavo)
Date: Mon, 28 Nov 2022 18:10:18 +0800
Subject: Replace the primitive class with a more general null safety?
Message-ID: <CAJL5A3mHh+wBK22vM-Nu=5y9TKbtHz=B41=ompHYr5PcrSBrTA@mail.gmail.com>

After I read the JEP and related documents of Project Valhalla, I doubted
the necessity of the existence of primitive classes.

It is impossible to migrate from identity class to primitive class, which
will break binary compatibility.
This is a big obstacle for third-party libraries to support Valhalla.
We can't even use the multi-release jar to make the API contain any
primitive classes, otherwise users must use the multi-release jar to
prevent crashes.

At the same time, in order to support non null types, the universal
generics draft also greatly undermines compatibility.

Although the value class is more compatible, it may not be inlined when it
is a field or array member.
Therefore, sometimes value objects are repeatedly boxed, which may have
worse performance than non value classes.
Providing both value class and primitive class may also make it more
difficult for users to choose.

I don't like the current draft very much. In particular, I am very
dissatisfied with the huge cost of providing null safety only for primitive
types.

Now I have an idea: it's time to provide generic non null types for Java.

Since the universal generics draft has decided to break compatibility, we
can go further and provide universal non null types in Java, just like
Kotlin.

Marking type as non null is a requirement of programmers for a long time,
and Kotlin's null safety is highly praised.
I think Valhalla is the best time for Java to introduce null safety.

If we do, we no longer need the primitive class. It is enough to mark the
value class as non null.
The problem that prevents us from migrating to the primitive class no
longer exists, because we don't need the primitive class and Q type anymore.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20221128/3e4baec2/attachment.htm>

From brian.goetz at oracle.com  Mon Nov 28 14:04:31 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 28 Nov 2022 14:04:31 +0000
Subject: Replace the primitive class with a more general null safety?
In-Reply-To: <CAJL5A3mHh+wBK22vM-Nu=5y9TKbtHz=B41=ompHYr5PcrSBrTA@mail.gmail.com>
References: <CAJL5A3mHh+wBK22vM-Nu=5y9TKbtHz=B41=ompHYr5PcrSBrTA@mail.gmail.com>
Message-ID: <82E11A2C-9F71-46E5-9A6E-56483C11FFF6@oracle.com>

There?s a lot of good thoughts in here (and some wishful thinking too), but most of it is well-covered ground.  

> After I read the JEP and related documents of Project Valhalla, I doubted the necessity of the existence of primitive classes.

We have been asking ourselves this question every day.  As the old saying goes, things should be as simple as possible, but no simpler.  Past attempts to simplify them away did not succeed, but that doesn?t mean we don?t keep trying.  

> It is impossible to migrate from identity class to primitive class, which will break binary compatibility.

This is not entirely true.  There are constraints involved, and at the appropriate time we will publish a migration guide, but it is not the case that you can?t migrate from B1 to either B2 or B3.  But this isn?t your real point.  

> At the same time, in order to support non null types, the universal generics draft also greatly undermines compatibility.

This is a pretty strong statement, and I?ve certainly not seen evidence for this.  But, again this is tangential to your point (and likely overstated to make your point sound better, though there?s no need for that), so let?s get to your point.  

> Although the value class is more compatible, it may not be inlined when it is a field or array member.

You?re confronting the essential physics of the problem; rejigging the packaging won?t change this.  But again, not your point.  

> I don't like the current draft very much. In particular, I am very dissatisfied with the huge cost of providing null safety only for primitive types.

The second sentence is the best part of your mail, pointing out that we?re incurring a lot of complexity whose benefit only accrues to some of the types.  This is indeed suboptimal. 

> Now I have an idea: it's time to provide generic non null types for Java.

You say this like it is a new idea!  We have explored this in *literally every iteration of Valhalla.*. At each iteration, we have asked ourselves whether the key distinctions could be replaced by general-purpose ?emotional? (bang and question) type operators, or whether even that notation is helpful or harmful to user intuition. At each point, the answer has been ?almost, but not quite.?  And in each iteration, we?ve continued to chip away at the difference, and ask ourselves the question again.  The current iteration is still a ?no?, but it is still a matter of active exploration, because *of course* Java developers would prefer this to the current val/ref scheme.  (Or at least some of them think they would.). 

> Since the universal generics draft has decided to break compatibility, we can go further

I don?t know what you mean by ?decided to break compatibility?, but even if that were true (and yes, there are small incompatibilities, such as ?what happens when you lock on Integer?), the rest would not remotely follow.  

>  and provide universal non null types in Java, just like Kotlin.


Haha, ?just?.  No.  Even if we were to find our way to non-null types, it would not be ?just? like anything.  

> If we do, we no longer need the primitive class. It is enough to mark the value class as non null.

Actually, no.  This is not the only difference between primitives and references.  If it were, we would have adopted this ?solution? a long time ago.  

As I said, there?s a lot of good thoughts in here, and the relationship between values and non-rulllable types has been a constant question along this journey, and still is.  We may be getting closer to having these concepts meet up.  But it is not ?just? anything.  Stay tuned.

From vromero at openjdk.org  Mon Nov 28 22:26:13 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 28 Nov 2022 22:26:13 GMT
Subject: [lworld] RFR: 8297207: [lworld] refactor primitive classes tests
 [v6]
In-Reply-To: <HGfZPrDce6feYL7EmFSZVrdzcXw9olLENvHU1Xhf5BM=.6ed0e5dd-f644-430d-b6c8-532a995bc05d@github.com>
References: <HGfZPrDce6feYL7EmFSZVrdzcXw9olLENvHU1Xhf5BM=.6ed0e5dd-f644-430d-b6c8-532a995bc05d@github.com>
Message-ID: <HaVU2btyDqtY6BH0sAbN1fmwBsCXcd-b8yyMfiJqBQ8=.b12e4098-da43-4cd8-a3ac-d16e17cbf090@github.com>

> refactoring primitive classes tests, consolidating compilation tests etc

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  remaining tests

-------------

Changes:
  - all: https://git.openjdk.org/valhalla/pull/811/files
  - new: https://git.openjdk.org/valhalla/pull/811/files/ff004449..fdc0281f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=valhalla&pr=811&range=05
 - incr: https://webrevs.openjdk.org/?repo=valhalla&pr=811&range=04-05

  Stats: 213 lines in 8 files changed: 103 ins; 110 del; 0 mod
  Patch: https://git.openjdk.org/valhalla/pull/811.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/811/head:pull/811

PR: https://git.openjdk.org/valhalla/pull/811

From vromero at openjdk.org  Mon Nov 28 22:31:55 2022
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 28 Nov 2022 22:31:55 GMT
Subject: [lworld] Integrated: 8297207: [lworld] refactor primitive classes
 tests
In-Reply-To: <HGfZPrDce6feYL7EmFSZVrdzcXw9olLENvHU1Xhf5BM=.6ed0e5dd-f644-430d-b6c8-532a995bc05d@github.com>
References: <HGfZPrDce6feYL7EmFSZVrdzcXw9olLENvHU1Xhf5BM=.6ed0e5dd-f644-430d-b6c8-532a995bc05d@github.com>
Message-ID: <GTwQmv4njAaY53ueP9mdgqi-XvS7YHRAPcaTtxS3-5Y=.9c1cb8a6-5344-447a-8dde-39d48955ccb5@github.com>

On Thu, 17 Nov 2022 21:38:47 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> refactoring primitive classes tests, consolidating compilation tests etc

This pull request has now been integrated.

Changeset: f689294b
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/f689294b07c3b56f4b5f65e18a6f04ef3a1121d0
Stats:     2425 lines in 65 files changed: 1269 ins; 1156 del; 0 mod

8297207: [lworld] refactor primitive classes tests

-------------

PR: https://git.openjdk.org/valhalla/pull/811

From rriggs at openjdk.org  Tue Nov 29 19:39:59 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 29 Nov 2022 19:39:59 GMT
Subject: [lworld] RFR: 8286824: [valhalla] WeakHashMap for value classes
 [v3]
In-Reply-To: <GEqB28hcKn7HCPs87eaFuYInmGDjTFrL_HCvQRoOJQg=.93972f1a-006a-4569-b458-6712eff21935@github.com>
References: <GEqB28hcKn7HCPs87eaFuYInmGDjTFrL_HCvQRoOJQg=.93972f1a-006a-4569-b458-6712eff21935@github.com>
Message-ID: <a7FSHbIyLS3SY8i6J2xkQUQ6rsOZnzw4Gyr-Gg1t_-0=.f246398f-a0ea-4ded-86ea-340c61e999fd@github.com>

> WeakHashMap uses WeakReference for keys, allowing it to retain only keys and values that are strongly referenced elsewhere.
> 
> The behavior of WeakReference (or any Reference class) is not defined for value objects.
> 
> Four (4) behaviors are proposed for WeakHashMap to give the developer a choice:
>  - SOFT - Keys that are value objects are retained until memory pressure clears soft references; then the keys that are value objects are removed automatically
>  - STRONG - Keys are value objects are retained until they are explicitly removed
>  - THROW - Keys that are value objects can not be put into the map; UnsupportedOperationException is thrown
>  - DISCARD - Keys that are value objects are silently discarded; as if they were removed immediately without being visible
> 
> The default is SOFT - key/values are removed when there is memory pressure.
> Entries will be removed automatically at some point, though less deterministically than with WeakReferences.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'lworld' into 8286824-weakhashmap
 - Merge branch 'lworld' into 8286824-weakhashmap
 - Fix bug when key is null.
   Change to throw IdentityException from WeakHashmap when
   a value object is put and the ValuePolicy is throw.
 - Merge branch 'lworld' into 8286824-weakhashmap
 - Merge branch 'lworld' into 8286824-weakhashmap
 - review comment updates
 - Merge
 - javadoc cleanup
 - replace newIdentity with 'new Object()'
 - fix NPE
 - ... and 4 more: https://git.openjdk.org/valhalla/compare/f689294b...93041b00

-------------

Changes: https://git.openjdk.org/valhalla/pull/718/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=718&range=02
  Stats: 466 lines in 3 files changed: 460 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/valhalla/pull/718.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/718/head:pull/718

PR: https://git.openjdk.org/valhalla/pull/718

From rriggs at openjdk.org  Wed Nov 30 22:27:07 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 30 Nov 2022 22:27:07 GMT
Subject: [lworld] Integrated: 8286824: [lworld] WeakHashMap for value classes
In-Reply-To: <GEqB28hcKn7HCPs87eaFuYInmGDjTFrL_HCvQRoOJQg=.93972f1a-006a-4569-b458-6712eff21935@github.com>
References: <GEqB28hcKn7HCPs87eaFuYInmGDjTFrL_HCvQRoOJQg=.93972f1a-006a-4569-b458-6712eff21935@github.com>
Message-ID: <4Gb7VoOORo8Po9eYQH1Wd8O_MVhQgEIBBdaj1trZ63Y=.ab984728-68c1-4f75-813f-124c7d1c1a1a@github.com>

On Thu, 30 Jun 2022 14:03:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> WeakHashMap uses WeakReference for keys, allowing it to retain only keys and values that are strongly referenced elsewhere.
> 
> The behavior of WeakReference (or any Reference class) is not defined for value objects.
> 
> Four (4) behaviors are proposed for WeakHashMap to give the developer a choice:
>  - SOFT - Keys that are value objects are retained until memory pressure clears soft references; then the keys that are value objects are removed automatically
>  - STRONG - Keys are value objects are retained until they are explicitly removed
>  - THROW - Keys that are value objects can not be put into the map; UnsupportedOperationException is thrown
>  - DISCARD - Keys that are value objects are silently discarded; as if they were removed immediately without being visible
> 
> The default is SOFT - key/values are removed when there is memory pressure.
> Entries will be removed automatically at some point, though less deterministically than with WeakReferences.

This pull request has now been integrated.

Changeset: a4c6473b
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/a4c6473bf48541170792305f97456b24fdb49528
Stats:     466 lines in 3 files changed: 460 ins; 1 del; 5 mod

8286824: [lworld] WeakHashMap for value classes

-------------

PR: https://git.openjdk.org/valhalla/pull/718