From thartmann at openjdk.org  Mon Jul  4 12:13:52 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 4 Jul 2022 12:13:52 GMT
Subject: [lworld] RFR: 8289686: [lworld] Unnecessary buffering because constant
 getters with scalarized arg are not C2 compiled
Message-ID: <Ivmecn9VXQDDvt8pNykGUOi39T7z-sLi7SYDeQJk3uQ=.80e94222-5f80-49da-8b07-6aa60dac627a@github.com>

The fix for [JDK-8275825](https://bugs.openjdk.org/browse/JDK-8275825) is incomplete. Getter methods returning a nullable inline type in scalarized form are still treated as trivial and therefore not C2 compiled which leads to buffering. Also, constant getter methods with an (unused) scalarized inline type receiver/argument should not be treated as trivial.

Thanks to @kuksenko for reporting!

Best regards,
Tobias

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

Commit messages:
 - 8289686: [lworld] Unnecessary buffering because constant getters with scalarized arg are not C2 compiled

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

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


From thartmann at openjdk.org  Mon Jul  4 12:15:24 2022
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 4 Jul 2022 12:15:24 GMT
Subject: [lworld] Integrated: 8289686: [lworld] Unnecessary buffering because
 constant getters with scalarized arg are not C2 compiled
In-Reply-To: <Ivmecn9VXQDDvt8pNykGUOi39T7z-sLi7SYDeQJk3uQ=.80e94222-5f80-49da-8b07-6aa60dac627a@github.com>
References: <Ivmecn9VXQDDvt8pNykGUOi39T7z-sLi7SYDeQJk3uQ=.80e94222-5f80-49da-8b07-6aa60dac627a@github.com>
Message-ID: <j5O4HJSOAzTFGYVCegVKsFJXkTn-W1M79dWAA42iJgU=.2b156bde-7130-437f-ae82-65de221e86ab@github.com>

On Mon, 4 Jul 2022 12:05:54 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The fix for [JDK-8275825](https://bugs.openjdk.org/browse/JDK-8275825) is incomplete. Getter methods returning a nullable inline type in scalarized form are still treated as trivial and therefore not C2 compiled which leads to buffering. Also, constant getter methods with an (unused) scalarized inline type receiver/argument should not be treated as trivial.
> 
> Thanks to @kuksenko for reporting!
> 
> Best regards,
> Tobias

This pull request has now been integrated.

Changeset: 0777b333
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/0777b3339ad9a41b13f285e8ba9fae25f2ef6e5e
Stats:     94 lines in 3 files changed: 87 ins; 0 del; 7 mod

8289686: [lworld] Unnecessary buffering because constant getters with scalarized arg are not C2 compiled

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

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


From dsimms at openjdk.org  Tue Jul  5 13:59:36 2022
From: dsimms at openjdk.org (David Simms)
Date: Tue, 5 Jul 2022 13:59:36 GMT
Subject: [lworld] RFR: 8289747: [lworld] Remove injected interfaces from CDS
 tests
Message-ID: <ESnqYZXagwMdEX4xB9GGR1UdXsrlU6mk4PyHR_hMis4=.9bbb01d8-a8c6-4545-a92f-8b63422f7485@github.com>

Revert previous test changes that accommodated interface injection

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

Commit messages:
 - 8289747: [lworld] Remove injected interfaces from CDS tests

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

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


From dsimms at openjdk.org  Tue Jul  5 14:02:12 2022
From: dsimms at openjdk.org (David Simms)
Date: Tue, 5 Jul 2022 14:02:12 GMT
Subject: [lworld] Integrated: 8289747: [lworld] Remove injected interfaces from
 CDS tests
In-Reply-To: <ESnqYZXagwMdEX4xB9GGR1UdXsrlU6mk4PyHR_hMis4=.9bbb01d8-a8c6-4545-a92f-8b63422f7485@github.com>
References: <ESnqYZXagwMdEX4xB9GGR1UdXsrlU6mk4PyHR_hMis4=.9bbb01d8-a8c6-4545-a92f-8b63422f7485@github.com>
Message-ID: <ousjSf2mt6GFSXcd26e2CFNjFy-wHg8O7AQPZACjbdc=.e19b77df-3610-4b5a-80d3-6f7f978de3a5@github.com>

On Tue, 5 Jul 2022 13:47:35 GMT, David Simms <dsimms at openjdk.org> wrote:

> Revert previous test changes that accommodated interface injection

This pull request has now been integrated.

Changeset: ce85ba8f
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/ce85ba8facb2dc17671b439714ec247ab48484fb
Stats:     17 lines in 4 files changed: 0 ins; 3 del; 14 mod

8289747: [lworld] Remove injected interfaces from CDS tests

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

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


From mchung at openjdk.org  Thu Jul  7 23:01:18 2022
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 7 Jul 2022 23:01:18 GMT
Subject: [lworld] RFR: 8286824: [valhalla] 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: <xLdtIJ57QB7pheDgsxF59wT-piIbrnN3iNasV7qUgQ8=.49434a96-a38a-4875-9bde-4a2b745bf709@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.

src/java.base/share/classes/java/util/WeakHashMap.java line 46:

> 44:  * mapping for a given key will not prevent the key from being discarded by the
> 45:  * garbage collector, that is, made finalizable, finalized, and then reclaimed.
> 46:  * For keys that are {@linkplain Class#isValue() Value objects}, the retention of the

should this be "value objects" rather than "Value objects"?  This comment applies to all occurrences.

src/java.base/share/classes/java/util/WeakHashMap.java line 81:

> 79:  * method.
> 80:  *
> 81:  * <p> <i>Update needed for Value Objects:

can you file a JBS issue to follow up this?

src/java.base/share/classes/java/util/WeakHashMap.java line 231:

> 229:      * The default {@code ValuePolicy} is {@link ValuePolicy#SOFT} unless
> 230:      * the system property {@systemProperty java.util.WeakHashMap.valueKeyRetention}
> 231:      * is equal to the name of a {@link ValuePolicy} enum.

Is the value of the system property case-sensitive?  should specify.

src/java.base/share/classes/java/util/WeakHashMap.java line 244:

> 242:     /**
> 243:      * Constructs a new, empty {@code WeakHashMap} with the given initial
> 244:      * capacity and the given load factor.

and the given value policy.

src/java.base/share/classes/java/util/WeakHashMap.java line 515:

> 513:      *         {@code null} if there was no mapping for {@code key}.
> 514:      *         (A {@code null} return can also indicate that the map
> 515:      *         previously associated {@code null} with {@code key}.)

Need to specify: A null return can also indicate the entry is discarded if the value policy is DISCARD and the key is a value object.

src/java.base/share/classes/java/util/WeakHashMap.java line 517:

> 515:      *         previously associated {@code null} with {@code key}.)
> 516:      * @throws UnsupportedOperationException if {@code key} is a Value object
> 517:      *         and the {@link #valuePolicy() valuePolicy} is {@link ValuePolicy#THROW}.

`putAll` and `putIfAbsent` would need spec update.

src/java.base/share/classes/java/util/WeakHashMap.java line 867:

> 865:     /**
> 866:      * A SoftEntry is used for value class keys in which the entries are retained
> 867:      * until there is some memory pressure.  A anchor object is used as the referent

s/a anchor/an anchor/

src/java.base/share/classes/java/util/WeakHashMap.java line 875:

> 873:      */
> 874:     private static class SoftEntry<K, V> extends Entry<K, V> {
> 875:         Object realKey;

can make it a final field.

src/java.base/share/classes/java/util/WeakHashMap.java line 920:

> 918:      */
> 919:     private static class StrongEntry<K, V> extends Entry<K, V> {
> 920:         Object realKey;

can be a final field

src/java.base/share/classes/java/util/WeakHashMap.java line 1534:

> 1532:     /**
> 1533:      * Enum for the ValuePolicy; when putting a key and value into a WeakHashMap
> 1534:      * determines how keys that are Value objects are retained (or not).

`@since valhalla`

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

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


From rriggs at openjdk.org  Fri Jul  8 16:04:03 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Jul 2022 16:04:03 GMT
Subject: [lworld] RFR: 8286824: [valhalla] WeakHashMap for value classes
In-Reply-To: <xLdtIJ57QB7pheDgsxF59wT-piIbrnN3iNasV7qUgQ8=.49434a96-a38a-4875-9bde-4a2b745bf709@github.com>
References: <GEqB28hcKn7HCPs87eaFuYInmGDjTFrL_HCvQRoOJQg=.93972f1a-006a-4569-b458-6712eff21935@github.com>
 <xLdtIJ57QB7pheDgsxF59wT-piIbrnN3iNasV7qUgQ8=.49434a96-a38a-4875-9bde-4a2b745bf709@github.com>
Message-ID: <5tG7F2uBDpd-GE_34AbzHTg_tw7NusXu32RM-psRYhc=.8725e8b4-1ab3-4661-8758-d40148e0949f@github.com>

On Thu, 7 Jul 2022 22:37:51 GMT, Mandy Chung <mchung 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.
>
> src/java.base/share/classes/java/util/WeakHashMap.java line 46:
> 
>> 44:  * mapping for a given key will not prevent the key from being discarded by the
>> 45:  * garbage collector, that is, made finalizable, finalized, and then reclaimed.
>> 46:  * For keys that are {@linkplain Class#isValue() Value objects}, the retention of the
> 
> should this be "value objects" rather than "Value objects"?  This comment applies to all occurrences.

I was thinking there needs to be a link target that explains value objects. Class.isValue doesn't see quite the right one. But verbiage will be needed somewhere.

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

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


From rriggs at openjdk.org  Fri Jul  8 15:56:59 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Jul 2022 15:56:59 GMT
Subject: [lworld] RFR: 8286824: [valhalla] WeakHashMap for value classes
In-Reply-To: <xLdtIJ57QB7pheDgsxF59wT-piIbrnN3iNasV7qUgQ8=.49434a96-a38a-4875-9bde-4a2b745bf709@github.com>
References: <GEqB28hcKn7HCPs87eaFuYInmGDjTFrL_HCvQRoOJQg=.93972f1a-006a-4569-b458-6712eff21935@github.com>
 <xLdtIJ57QB7pheDgsxF59wT-piIbrnN3iNasV7qUgQ8=.49434a96-a38a-4875-9bde-4a2b745bf709@github.com>
Message-ID: <jZjlfITOEbBZQw42trIYweMpBLn9652-Tzs1_kztCVE=.107330fb-2f07-43f5-b0ce-9c26596f61e8@github.com>

On Thu, 7 Jul 2022 22:36:02 GMT, Mandy Chung <mchung 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.
>
> src/java.base/share/classes/java/util/WeakHashMap.java line 231:
> 
>> 229:      * The default {@code ValuePolicy} is {@link ValuePolicy#SOFT} unless
>> 230:      * the system property {@systemProperty java.util.WeakHashMap.valueKeyRetention}
>> 231:      * is equal to the name of a {@link ValuePolicy} enum.
> 
> Is the value of the system property case-sensitive?  should specify.

Enum names are case-sensitive; I'll expand to refer to `ValuePolicy.valueOf` for the value of the property.

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

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


From rriggs at openjdk.org  Fri Jul  8 16:10:01 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Jul 2022 16:10:01 GMT
Subject: [lworld] RFR: 8286824: [valhalla] WeakHashMap for value classes
In-Reply-To: <xLdtIJ57QB7pheDgsxF59wT-piIbrnN3iNasV7qUgQ8=.49434a96-a38a-4875-9bde-4a2b745bf709@github.com>
References: <GEqB28hcKn7HCPs87eaFuYInmGDjTFrL_HCvQRoOJQg=.93972f1a-006a-4569-b458-6712eff21935@github.com>
 <xLdtIJ57QB7pheDgsxF59wT-piIbrnN3iNasV7qUgQ8=.49434a96-a38a-4875-9bde-4a2b745bf709@github.com>
Message-ID: <GxiJI0dAaJX8qsv-5tYL7Qe8gPO9Fnk5Hw-lr75Zne0=.25045df9-1c73-446b-a1a6-a5153dc9c865@github.com>

On Thu, 7 Jul 2022 22:41:55 GMT, Mandy Chung <mchung 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.
>
> src/java.base/share/classes/java/util/WeakHashMap.java line 515:
> 
>> 513:      *         {@code null} if there was no mapping for {@code key}.
>> 514:      *         (A {@code null} return can also indicate that the map
>> 515:      *         previously associated {@code null} with {@code key}.)
> 
> Need to specify: A null return can also indicate the entry is discarded if the value policy is DISCARD and the key is a value object.

A subtle point...  The WeakHashmap *may* contain an identity class instance that compares as `equals()` with the value object. In that case, the instance would be returned from `getEntry`.
Similarly, `put()` would return the previous entry (that was `equals`) to a value entry that is discarded.
This will need some more spec detail.

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

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


From brian.goetz at oracle.com  Wed Jul 27 16:10:19 2022
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 27 Jul 2022 12:10:19 -0400
Subject: Fwd: What about Array.newInstance for restricted value-types?
In-Reply-To: <858d75e8-f339-9e6a-5a49-f867943fa924@gmail.com>
References: <858d75e8-f339-9e6a-5a49-f867943fa924@gmail.com>
Message-ID: <460a5249-c8ed-ebd7-cd88-456be67bb368@oracle.com>

Received on the -comments list.

Yes, this issue is well understood; I believe John has written about 
this on the -experts list already, or if not he will soon.? Reflection 
frequently has to bake back in access control checks that otherwise 
would be done by the VM during linkage, and many reflective methods are 
caller-sensitive for exactly this reason.

Do you? have any reason to believe that the standard techniques of 
securing reflection would result in problems?


-------- Forwarded Message --------
Subject: 	What about Array.newInstance for restricted value-types?
Date: 	Tue, 26 Jul 2022 14:38:05 +0200
From: 	Gernot Neppert <mcnepp02 at googlemail.com>
To: 	valhalla-spec-comments at openjdk.java.net




There is an ongoing discussion about how to prevent the creation of 
values with non-sensible zero-defaults.

Currently, the consensus seems to be that restricting access to a 
value-type's "companion-type" will achieve this.

However, I found this Anomaly:

The method java.lang.reflect.Array.newInstance(Class<?> 
componentType,int length) currently does not take the accessibility of 
the "componentType" into account!

So, it looks as if one could still create flat, zero-initialized arrays 
of private companion-types from anywhere in the codebase:

package org.secrets;

public value class Bar {

 ??? private value companion Bar.val;

}

package com.external;

import java.lang.reflect.Array;

public class Main {

 ???? Bar[] bars = 
(Bar[])Array.newInstance(Class.forName("org.secrets.Bar.val"), 42);

}






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20220727/80e2ca9a/attachment.htm>

From fparain at openjdk.org  Wed Jul 27 17:38:19 2022
From: fparain at openjdk.org (Frederic Parain)
Date: Wed, 27 Jul 2022 17:38:19 GMT
Subject: [lworld] RFR: Switch to modifier model to handle value and identity
 classes
Message-ID: <B-J22PbbccNeNJlnbHVLmHHCXrTtNgQLwQvF4q2igso=.2ff7979e-3e3d-4681-a213-3dc7857f59d6@github.com>

VM side of the support for the new modifier based model to handle value and identity classes.

Many changes in this PR:
  - remove unused code still referencing ACC_SUPER
  - remove deprecated PERMITS_VALUE code
  - remove interface injection code
  - implement support for new class modifiers ACC_IDENTITY/ACC_VALUE/ACC_PRIMITIVE
  - fixed Proxy class generation to produce correct access flags
  - update many tests to conform to the new model

Thanks to Roger for his help on the Java side.

Still some tests failing in tier1-3, but pushing the VM code would enable other people to work on issues on the Java side.

Thank you,

Fred

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

Commit messages:
 - More Java fix
 - Roger's patch and some clean up
 - Merge remote-tracking branch 'upstream/lworld' into new_super_rules
 - Merge remote-tracking branch 'upstream/lworld' into new_super_rules
 - Merge remote-tracking branch 'upstream/lworld' into new_super_rules
 - Integrate Roger's patch for libraries code and tests
 - Switch to modifier model to handle value and identity classes

Changes: https://git.openjdk.org/valhalla/pull/714/files
 Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=714&range=00
  Stats: 1747 lines in 75 files changed: 1358 ins; 181 del; 208 mod
  Patch: https://git.openjdk.org/valhalla/pull/714.diff
  Fetch: git fetch https://git.openjdk.org/valhalla pull/714/head:pull/714

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


From dsimms at openjdk.org  Thu Jul 28 11:16:07 2022
From: dsimms at openjdk.org (David Simms)
Date: Thu, 28 Jul 2022 11:16:07 GMT
Subject: [lworld] RFR: Switch to modifier model to handle value and
 identity classes
In-Reply-To: <B-J22PbbccNeNJlnbHVLmHHCXrTtNgQLwQvF4q2igso=.2ff7979e-3e3d-4681-a213-3dc7857f59d6@github.com>
References: <B-J22PbbccNeNJlnbHVLmHHCXrTtNgQLwQvF4q2igso=.2ff7979e-3e3d-4681-a213-3dc7857f59d6@github.com>
Message-ID: <2e-YZYXbcAJhfZk8F1m2hSjhrRevr1Xw8HXywDMqagM=.67e063f4-2ad8-4385-9307-0f73db4fbacc@github.com>

On Wed, 15 Jun 2022 16:11:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> VM side of the support for the new modifier based model to handle value and identity classes.
> 
> Many changes in this PR:
>   - remove unused code still referencing ACC_SUPER
>   - remove deprecated PERMITS_VALUE code
>   - remove interface injection code
>   - implement support for new class modifiers ACC_IDENTITY/ACC_VALUE/ACC_PRIMITIVE
>   - fixed Proxy class generation to produce correct access flags
>   - update many tests to conform to the new model
> 
> Thanks to Roger for his help on the Java side.
> 
> Still some tests failing in tier1-3, but pushing the VM code would enable other people to work on issues on the Java side.
> 
> Thank you,
> 
> Fred

Wow, yeah a lot of Java / JDK changes for that modifier, looks good

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

Marked as reviewed by dsimms (Committer).

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


From fparain at openjdk.org  Thu Jul 28 12:53:11 2022
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 28 Jul 2022 12:53:11 GMT
Subject: [lworld] RFR: Switch to modifier model to handle value and
 identity classes
In-Reply-To: <B-J22PbbccNeNJlnbHVLmHHCXrTtNgQLwQvF4q2igso=.2ff7979e-3e3d-4681-a213-3dc7857f59d6@github.com>
References: <B-J22PbbccNeNJlnbHVLmHHCXrTtNgQLwQvF4q2igso=.2ff7979e-3e3d-4681-a213-3dc7857f59d6@github.com>
Message-ID: <WN7nftAtH6PVTzCA3WTjd2msVGibNcDLTq6lERO8Los=.bff36fe4-0030-47f6-8846-375c6f020730@github.com>

On Wed, 15 Jun 2022 16:11:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> VM side of the support for the new modifier based model to handle value and identity classes.
> 
> Many changes in this PR:
>   - remove unused code still referencing ACC_SUPER
>   - remove deprecated PERMITS_VALUE code
>   - remove interface injection code
>   - implement support for new class modifiers ACC_IDENTITY/ACC_VALUE/ACC_PRIMITIVE
>   - fixed Proxy class generation to produce correct access flags
>   - update many tests to conform to the new model
> 
> Thanks to Roger for his help on the Java side.
> 
> Still some tests failing in tier1-3, but pushing the VM code would enable other people to work on issues on the Java side.
> 
> Thank you,
> 
> Fred

Thank you Mr Simms for the review.

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

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


From fparain at openjdk.org  Thu Jul 28 12:56:39 2022
From: fparain at openjdk.org (Frederic Parain)
Date: Thu, 28 Jul 2022 12:56:39 GMT
Subject: [lworld] Integrated: Switch to modifier model to handle value and
 identity classes
In-Reply-To: <B-J22PbbccNeNJlnbHVLmHHCXrTtNgQLwQvF4q2igso=.2ff7979e-3e3d-4681-a213-3dc7857f59d6@github.com>
References: <B-J22PbbccNeNJlnbHVLmHHCXrTtNgQLwQvF4q2igso=.2ff7979e-3e3d-4681-a213-3dc7857f59d6@github.com>
Message-ID: <8w5mXwZae1b0g1hZCkceBBdGq1InWFoBMYU60gR9ClY=.c2b47055-e6e1-45af-a83c-2a68bb9d5b20@github.com>

On Wed, 15 Jun 2022 16:11:46 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> VM side of the support for the new modifier based model to handle value and identity classes.
> 
> Many changes in this PR:
>   - remove unused code still referencing ACC_SUPER
>   - remove deprecated PERMITS_VALUE code
>   - remove interface injection code
>   - implement support for new class modifiers ACC_IDENTITY/ACC_VALUE/ACC_PRIMITIVE
>   - fixed Proxy class generation to produce correct access flags
>   - update many tests to conform to the new model
> 
> Thanks to Roger for his help on the Java side.
> 
> Still some tests failing in tier1-3, but pushing the VM code would enable other people to work on issues on the Java side.
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: 3dc006bd
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.org/valhalla/commit/3dc006bdba0e0101ac19831cead88e6f5eefa34b
Stats:     1747 lines in 75 files changed: 1358 ins; 181 del; 208 mod

Switch to modifier model to handle value and identity classes

Reviewed-by: dsimms

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

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