From dsimms at openjdk.java.net  Tue Dec  1 09:17:16 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 1 Dec 2020 09:17:16 GMT
Subject: [lworld] Integrated: [lworld] Missed disabling testcase that does not
 pack well with -XX:ForceNonTearable
Message-ID: <ROGkJAO0m1IVOVBlWq58AUXC4XvvGppmWFc4djkoeCo=.a3f208a9-8dab-451c-bc8e-82812d872a48@github.com>

Disable testAlignedSize for -XX:ForceNonTearable

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

Commit messages:
 - [lworld] Missed disabling testcase that does not pack well with  -XX:ForceNonTearable

Changes: https://git.openjdk.java.net/valhalla/pull/284/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=284&range=00
  Stats: 9 lines in 1 file changed: 2 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/284.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/284/head:pull/284

PR: https://git.openjdk.java.net/valhalla/pull/284

From dsimms at openjdk.java.net  Tue Dec  1 09:17:16 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Tue, 1 Dec 2020 09:17:16 GMT
Subject: [lworld] Integrated: [lworld] Missed disabling testcase that does not
 pack well with -XX:ForceNonTearable
In-Reply-To: <ROGkJAO0m1IVOVBlWq58AUXC4XvvGppmWFc4djkoeCo=.a3f208a9-8dab-451c-bc8e-82812d872a48@github.com>
References: <ROGkJAO0m1IVOVBlWq58AUXC4XvvGppmWFc4djkoeCo=.a3f208a9-8dab-451c-bc8e-82812d872a48@github.com>
Message-ID: <fjHEt9oh3Z9oDgBh9gQdx7t2q3GIvXgB5FgxGw2qjcM=.bb241c32-a3ae-41e2-a4b4-671716ce1c72@github.com>

On Tue, 1 Dec 2020 09:09:49 GMT, David Simms <dsimms at openjdk.org> wrote:

> Disable testAlignedSize for -XX:ForceNonTearable

This pull request has now been integrated.

Changeset: 1abd0379
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/1abd0379
Stats:     9 lines in 1 file changed: 2 ins; 2 del; 5 mod

[lworld] Missed disabling testcase that does not pack well with  -XX:ForceNonTearable

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

PR: https://git.openjdk.java.net/valhalla/pull/284

From mchung at openjdk.java.net  Tue Dec  1 18:29:12 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 1 Dec 2020 18:29:12 GMT
Subject: [lworld] RFR: 8231500: [lworld] Merge the experimental bytecode
 API
In-Reply-To: <T_4H65CZfk5uY1pe_ZOBVapPWALQ504zkUVnWHfM3Q4=.f6761833-3958-4dce-9b71-b6da81d610cd@github.com>
References: <T_4H65CZfk5uY1pe_ZOBVapPWALQ504zkUVnWHfM3Q4=.f6761833-3958-4dce-9b71-b6da81d610cd@github.com>
Message-ID: <1Fb9TjCKecszA_1SeWUw7qJhS3H_amRAeYkE6ZXfOcs=.f5491814-e1a6-40a9-b44f-88265171ab6a@github.com>

On Wed, 25 Nov 2020 11:58:55 GMT, David Simms <dsimms at openjdk.org> wrote:

> * Moved to a single bytecode testing API
> * Cleaned out vbytecodes
> * Cleanup of tests not actually using the API
> * Removed TestNativeClone's API usage since cooking the method handle could no
> longer bypass the verifier's bad access check

Looks okay in general.   For the new methods like `isValue`, `valueType` and `putValueClass` etc, they should be renamed to reflect the new terminology (inline class).

test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java line 271:

> 269: 
> 270:             @Override
> 271:             public boolean isValue(String desc) {

I think we should rename `isValue` to `isInlineClass` and also other new `xxxValue` methods

test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java line 171:

> 169:     }
> 170: 
> 171:     public static MethodHandle loadCode(MethodHandles.Lookup lookup, String className, String methodName, MethodType type, Consumer<? super MethodHandleCodeBuilder<?>> builder) {

Are these two `loadCode` methods taking a builder `Consumer` used by the tests?

If so, the following classes and methods can be made private to hide them as internals.

test/jdk/lib/testlibrary/bytecode/jdk/experimental/bytecode/BasicTypeHelper.java line 49:

> 47: 
> 48:     @Override
> 49:     public boolean isValue(String t) {

s/isValue/isInlineClass/

test/jdk/lib/testlibrary/bytecode/jdk/experimental/bytecode/BasicTypeHelper.java line 59:

> 57: 
> 58:     @Override
> 59:     public String valueType(String s) {

s/valueType/inlineType/

test/jdk/lib/testlibrary/bytecode/jdk/experimental/bytecode/BytePoolHelper.java line 341:

> 339: 
> 340:     @Override
> 341:     public int putValueClass(S symbol) {

s/putValueClass/putInlineClass/

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

PR: https://git.openjdk.java.net/valhalla/pull/279

From sergey.kuksenko at oracle.com  Wed Dec  2 01:26:50 2020
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Tue, 1 Dec 2020 17:26:50 -0800
Subject: UseACmpProfile question.
In-Reply-To: <87im9sjm5v.fsf@redhat.com>
References: <6e54062d-a9f4-6a03-9d41-ec37ea658bc6@oracle.com>
 <87tutekjcd.fsf@redhat.com> <defc557b-d6d4-c116-d9d3-79ad58a327da@oracle.com>
 <87im9sjm5v.fsf@redhat.com>
Message-ID: <1fdf6f43-f542-a7f8-b510-413c679b111a@oracle.com>

Thank you for this advice. I managed to get necessary code just playing 
with profile (provide proper values at runtime).

Looks like acmp profiling performance results are transforming from a 
simple email to a large report. Need time to process all scenarios.

On 11/26/20 5:13 AM, Roland Westrelin wrote:
>> Thank you. It's better, but not end.
>>
>> How to turn off null values profiling?
> There's no command line option for that. C2 guesses that there are no
> null values and if that triggers a deoptimization then on recompilation
> it doesn't try to guess anymore. You would have to edit the code:
>
> https://urldefense.com/v3/__https://github.com/openjdk/valhalla/blob/lworld/src/hotspot/share/opto/parse2.cpp*L2058__;Iw!!GqivPVa7Brio!LBkWI8wCSRvp4hg-6lLmfKWsZ-3i5sL0qNX00g3nDTzn9-kkoahx_7JCyRwhRuTiw2Bf$
>
> and pass false instead.
>
> Roland.
>

From thartmann at openjdk.java.net  Wed Dec  2 07:33:15 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 2 Dec 2020 07:33:15 GMT
Subject: [lworld] RFR: 8257422: [lworld] Problems with scalarized inline type
 return and incremental inlining
Message-ID: <5tvzjFNTD6BKxRoIjQAPBndCyUZ7Rqjkl8V5vW4AsDo=.c3212105-481a-47e3-80ee-8e7dfc873c6e@github.com>

TestCallingConvention spuriously fails with -Xcomp and -XX:-TieredCompilation due to incremental inlining not properly handling scalarized inline type returns in rare cases. The actual fix is in parse1.cpp where we accidentally use an inline type PhiNode to return an inline type ptr when incrementally inlining (in some cases, that also manifests as crashes during compilation).

I've also refactored some related code, added stronger asserts, improved comments and added tests that reproduce the issue more reliably.

Thanks,
Tobias

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

Commit messages:
 - 8257422: [lworld] Problems with scalarized inline type return and incremental inlining

Changes: https://git.openjdk.java.net/valhalla/pull/285/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=285&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257422
  Stats: 98 lines in 5 files changed: 67 ins; 5 del; 26 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/285.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/285/head:pull/285

PR: https://git.openjdk.java.net/valhalla/pull/285

From john.r.rose at oracle.com  Wed Dec  2 08:06:47 2020
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 2 Dec 2020 00:06:47 -0800
Subject: Typed variants of primitives
In-Reply-To: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>
References: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>
Message-ID: <F0FDCFB9-D95D-41EA-A0B6-7DAB199FA1A5@oracle.com>

On Nov 29, 2020, at 4:13 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
> I wanted to raise a concept that I don't remember seeing as part of
> the valhalla work so far, and I'll do so via a java.time.* example.
> ?
> Now of course, it is almost certainly pie-in-the-sky to try and make
> something this backwards compatible. But what about new types? In API
> design terms, there is appeal in defining a type that restricts the
> valid set of ints, for example a `PositiveInt` value type. But without
> the associated boxing/unboxing to `int` and maths operator-overloading
> it is generally more pain than it is worth to design an API that way.
> Has this concept been considered?

I think this concept is subsumed within the larger topic
of ?user defined primitives?, which itself has several sides
including the ones you bring up.

Make Year be a user-defined primitive backed by a sufficiently
large built-in primitive, say int or short.  As a class-based type,
it will have {de-,re-,}constructors and field extractors to wrap
and unwrap a bare integral value.  The wrap operation
(constructor) can validate the year, if that?s desirable.  The
unwrap operation can just expose the integral value,
perhaps with special processing in the case of the default
value for Year (Year.default).

That?s enough to get going, I think.  And it?s about the same
story as if you were making user-defined (class-based) primitives
for complex numbers, unsigned integers, jumbo integers,
tiny floats, or SIMD vectors.

Maybe we want to do arithmetic using natural Java expression
notation; that?s a reasonable thing to want, though it?s hard to
do well.  (?Just overload operators like C++ kthxbi? is easy but
almost certainly wrong.)  There are lots of options here.

Maybe we want an automatic story for migrating from int-based
to Year-based API points, as you suggest. Again, a reasonable ask,
but it requires not only a flexible way for establish type mappings
(between old and new types) and a way for marking methods
for migration, but also a delicately balanced set of rules that
will tend to prevent surprises and errors.  Again, lots of options.
Note that user-defined operators is a near neighbor to user-defined
conversions (e.g., in C++) and so perhaps a solution for natural
expression notation can be parleyed into a solution for organizing
migration type conversions.

My working title for the JVM support for morphing types of API
points is ?Bridge-O-Matic? (considered narrowly), or more broadly
?Method Implementation Dynamic?(friends call it ?mindy?).  The
basic idea is to allow the JVM?s dynamic linker mechanism fall
back from a failed signature match to a call to a related entry
point, as if via MH.invoke instead of MH.invokeExact.  I don?t
know what the language-level notation for setting up such a
fallback would look like.  I mention it here because, if you can
allow Year and int to agree on an implicit conversion (arguably
a sub-goal for natural expressions on user-defined primitives),
then you could ask the JVM to apply an asType transform
including such a conversion to help you adjust the mismatch
between a caller and callee.

Also, there?s no need for a fully-dynamic Bridge-O-Matic
if javac is somehow tasked with emitting static bridges that
contain (perhaps statically or perhaps via indy+asType)
the required conversions.  Such static bridges would be,
I presume, marked ?Synthetic?, so that they would not
appear as API points visible to source code, just JVM-callable
legacy methods for down-rev code.

So, yes, we?ve thought about this stuff in various venues, and
it seems that your concerns could be handled by a mix of
?user defined primitives done right? and ?method signature
migration done right?.  Did I miss anything?

? John

From dsimms at openjdk.java.net  Wed Dec  2 08:32:06 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Dec 2020 08:32:06 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <hVn6lfp3T_CpC7F8eaujARg5qyAY0c-b87rewhaAaqk=.ce047c3a-e083-47e9-afca-079addb1bc79@github.com>

Merge tag 'jdk-16+26'

* output.cpp: Ignore new assert for now

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

Commit messages:
 - Ignore new assert for now
 - Fix logical compile errors from merge
 - Merge tag 'jdk-16+26' into lworld_merge_jdk_16_26
 - 8256016: Dacapo24H.java failed with "assert(false) failed: unscheduable graph"
 - 8256489: Make gtest for long path names on Windows more resilient in the presence of virus scanners
 - 8257056: Submit workflow should apt-get update to avoid package installation errors
 - 8256755: Update build.tools.depend.Depend to handle record components in API signatures
 - 8256865: Foreign Memory Access and Linker API are missing NPE checks
 - 8243315: ParallelScavengeHeap::initialize() passes GenAlignment as page size to os::trace_page_sizes instead of actual page size
 - 8255904: Remove superfluous use of reflection in Class::isRecord
 - ... and 137 more: https://git.openjdk.java.net/valhalla/compare/9108c124...d9487db2

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=286&range=00.0
 - jdk: https://webrevs.openjdk.java.net/?repo=valhalla&pr=286&range=00.1

Changes: https://git.openjdk.java.net/valhalla/pull/286/files
  Stats: 180977 lines in 1018 files changed: 120659 ins; 46560 del; 13758 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/286.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/286/head:pull/286

PR: https://git.openjdk.java.net/valhalla/pull/286

From scolebourne at joda.org  Wed Dec  2 08:53:41 2020
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 2 Dec 2020 08:53:41 +0000
Subject: Typed variants of primitives
In-Reply-To: <F0FDCFB9-D95D-41EA-A0B6-7DAB199FA1A5@oracle.com>
References: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>
 <F0FDCFB9-D95D-41EA-A0B6-7DAB199FA1A5@oracle.com>
Message-ID: <CACzrW9CxEJRX6Bka6Lu8an8=gnWPb9rVhZp97KLk46JMaMG4TQ@mail.gmail.com>

On Wed, 2 Dec 2020 at 08:07, John Rose <john.r.rose at oracle.com> wrote:
> Did I miss anything?

I don't think so, it all looks possible though no doubt very long
term. The only point I'd note is that Year.default is not a valid
year, thus more akin to null, but nulls are a whole other topic.

I asked because a question was raised to me as to whether we should
add method overloads pre-valhalla to certain APIs in java.time.*.
  current: LocalDate.of(int, int, int)
  current: LocalDate.of(int, Month, int)
  add overload in Java 17?: LocalDate.of(Year, Month, int)

I think you'd suggest not to do that, but just want to be sure.

thanks
Stephen

From dsimms at openjdk.java.net  Wed Dec  2 08:56:49 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Dec 2020 08:56:49 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <hVn6lfp3T_CpC7F8eaujARg5qyAY0c-b87rewhaAaqk=.ce047c3a-e083-47e9-afca-079addb1bc79@github.com>
References: <hVn6lfp3T_CpC7F8eaujARg5qyAY0c-b87rewhaAaqk=.ce047c3a-e083-47e9-afca-079addb1bc79@github.com>
Message-ID: <a1nWAm8gyp9D8VxJ2sp-lwVVyrI_C1hAxAa1f9EsNJk=.d2959313-1ae2-44fb-a540-66f0abb2ff93@github.com>

> Merge tag 'jdk-16+26'
> 
> * output.cpp: Ignore new assert for now

David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 1049 commits:

 - Ignore new assert for now
 - Fix logical compile errors from merge
 - Merge tag 'jdk-16+26' into lworld_merge_jdk_16_26
   
   Added tag jdk-16+26 for changeset 7aed9b65
   
   # Conflicts:
   #	.github/workflows/submit.yml
   #	src/hotspot/share/c1/c1_IR.hpp
   #	src/hotspot/share/ci/ciSignature.cpp
   #	src/hotspot/share/ci/ciSignature.hpp
   #	src/hotspot/share/ci/ciType.cpp
   #	src/hotspot/share/code/compiledMethod.cpp
   #	src/hotspot/share/code/pcDesc.hpp
   #	src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
   #	src/hotspot/share/opto/callGenerator.cpp
   #	src/hotspot/share/opto/graphKit.hpp
   #	src/hotspot/share/opto/macro.hpp
   #	src/hotspot/share/opto/output.cpp
   #	src/hotspot/share/runtime/sharedRuntime.hpp
   #	src/hotspot/share/runtime/vmOperations.hpp
   #	src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
 - 8256929: [lworld] Fails to compile with --with-debug-level=optimized
 - Merge jdk
   
   Merge tag 'jdk-16+25'
 - 8256481: [lworld] C2 fails to eliminate GC barriers when replacing inline type buffer allocation
 - 8255995: templateTable_x86.cpp (TemplateTable::if_acmp) not always do correct null check.
   
   Reviewed-by: fparain, thartmann
 - 8238369: [lworld] Incorrect layout of inline type in flattened array.
   
   Reviewed-by: fparain
 - Disable further BiasedLocking tests
 - 8255522: [lworld] References to biased pattern remain in markWord::is_unlocked()
   
   Reviewed-by: fparain, skuksenko
 - ... and 1039 more: https://git.openjdk.java.net/valhalla/compare/7aed9b65...d9487db2

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

Changes: https://git.openjdk.java.net/valhalla/pull/286/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=286&range=01
  Stats: 152162 lines in 1338 files changed: 145352 ins; 2272 del; 4538 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/286.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/286/head:pull/286

PR: https://git.openjdk.java.net/valhalla/pull/286

From dsimms at openjdk.java.net  Wed Dec  2 08:56:55 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Dec 2020 08:56:55 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <hVn6lfp3T_CpC7F8eaujARg5qyAY0c-b87rewhaAaqk=.ce047c3a-e083-47e9-afca-079addb1bc79@github.com>
References: <hVn6lfp3T_CpC7F8eaujARg5qyAY0c-b87rewhaAaqk=.ce047c3a-e083-47e9-afca-079addb1bc79@github.com>
Message-ID: <3_HwyzJTyWZUjQDB95SgvatdHFV1_tBe11Fd_7YwChM=.e1273578-529c-4856-a75c-e4883d7566d7@github.com>

On Wed, 2 Dec 2020 08:21:10 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+26'
> 
> * output.cpp: Ignore new assert for now

This pull request has now been integrated.

Changeset: 8efeb68e
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/8efeb68e
Stats:     180977 lines in 1018 files changed: 120659 ins; 46560 del; 13758 mod

Merge jdk

Merge tag 'jdk-16+26'

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

PR: https://git.openjdk.java.net/valhalla/pull/286

From dsimms at openjdk.java.net  Wed Dec  2 08:57:13 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Dec 2020 08:57:13 GMT
Subject: Integrated: Merge lworld
Message-ID: <kDwkDp06UObykv0c5ZGQJ185wA6oAINDdptaZB9ONK0=.aee42220-93f7-46f1-9eea-fd194ca3fdc3@github.com>

Merge branch 'lworld' into type-restrictions_merge_jdk_16_26

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

Commit messages:
 - Merge branch 'lworld' into type-restrictions_merge_jdk_16_26
 - 8257028: [type-restrictions] Assorted issues with generation of RestrictedField attributes from annotations
 - 8255856: Generate RestrictedField attributes from annotations
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - Merge lworld
 - 8254254: [lworld][type-restrictions] Serviceability tests failing missing FIELDINFO_TAG_MASK
 - ... and 4 more: https://git.openjdk.java.net/valhalla/compare/8efeb68e...61afcfe3

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/valhalla/pull/287/files
  Stats: 946 lines in 42 files changed: 894 ins; 5 del; 47 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/287.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/287/head:pull/287

PR: https://git.openjdk.java.net/valhalla/pull/287

From dsimms at openjdk.java.net  Wed Dec  2 08:57:18 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Dec 2020 08:57:18 GMT
Subject: Integrated: Merge lworld
In-Reply-To: <kDwkDp06UObykv0c5ZGQJ185wA6oAINDdptaZB9ONK0=.aee42220-93f7-46f1-9eea-fd194ca3fdc3@github.com>
References: <kDwkDp06UObykv0c5ZGQJ185wA6oAINDdptaZB9ONK0=.aee42220-93f7-46f1-9eea-fd194ca3fdc3@github.com>
Message-ID: <5QcZ1vNV9N5kEdGd-jmyxLF2YuDww8-aWNifxremdfs=.3deb9fff-2100-42b2-9120-439c012e0f8c@github.com>

On Wed, 2 Dec 2020 08:50:39 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge branch 'lworld' into type-restrictions_merge_jdk_16_26

This pull request has now been integrated.

Changeset: 2f7d9f74
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/2f7d9f74
Stats:     181067 lines in 1024 files changed: 120695 ins; 46565 del; 13807 mod

Merge lworld

Merge tag 'jdk-16+26'

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

PR: https://git.openjdk.java.net/valhalla/pull/287

From thartmann at openjdk.java.net  Wed Dec  2 09:50:07 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 2 Dec 2020 09:50:07 GMT
Subject: [lworld] Integrated: 8257422: [lworld] Problems with scalarized
 inline type return and incremental inlining
In-Reply-To: <5tvzjFNTD6BKxRoIjQAPBndCyUZ7Rqjkl8V5vW4AsDo=.c3212105-481a-47e3-80ee-8e7dfc873c6e@github.com>
References: <5tvzjFNTD6BKxRoIjQAPBndCyUZ7Rqjkl8V5vW4AsDo=.c3212105-481a-47e3-80ee-8e7dfc873c6e@github.com>
Message-ID: <hY8gRDSGghd2CthHMki4fJQEeZhA-pJYBBq_Vi9AEKU=.d8e2b91f-b92a-440c-a3a2-57cf8c0c9e7c@github.com>

On Wed, 2 Dec 2020 07:29:06 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> TestCallingConvention spuriously fails with -Xcomp and -XX:-TieredCompilation due to incremental inlining not properly handling scalarized inline type returns in rare cases. The actual fix is in parse1.cpp where we accidentally use an inline type PhiNode to return an inline type ptr when incrementally inlining (in some cases, that also manifests as crashes during compilation).
> 
> I've also refactored some related code, added stronger asserts, improved comments and added tests that reproduce the issue more reliably.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 86801524
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/86801524
Stats:     98 lines in 5 files changed: 67 ins; 5 del; 26 mod

8257422: [lworld] Problems with scalarized inline type return and incremental inlining

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

PR: https://git.openjdk.java.net/valhalla/pull/285

From rwestrel at redhat.com  Wed Dec  2 10:02:10 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Wed, 02 Dec 2020 11:02:10 +0100
Subject: UseACmpProfile question.
In-Reply-To: <1fdf6f43-f542-a7f8-b510-413c679b111a@oracle.com>
References: <6e54062d-a9f4-6a03-9d41-ec37ea658bc6@oracle.com>
 <87tutekjcd.fsf@redhat.com>
 <defc557b-d6d4-c116-d9d3-79ad58a327da@oracle.com>
 <87im9sjm5v.fsf@redhat.com>
 <1fdf6f43-f542-a7f8-b510-413c679b111a@oracle.com>
Message-ID: <87czzsjzkt.fsf@redhat.com>


> Looks like acmp profiling performance results are transforming from a 
> simple email to a large report. Need time to process all scenarios.

Great. What about aaload/aastore profiling? I think you said before that
there are scenarios where that profiling helps quite a bit. We try hard
to perform well when profile data is not available. That that profiling
helps that much may be a sign that we could do better when it's
unavailable. I think it would be helpful if we could take a look at
those cases.

Roland.


From dsimms at openjdk.java.net  Wed Dec  2 10:28:19 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Dec 2020 10:28:19 GMT
Subject: [lworld] RFR: 8231500: [lworld] Merge the experimental bytecode
 API [v2]
In-Reply-To: <T_4H65CZfk5uY1pe_ZOBVapPWALQ504zkUVnWHfM3Q4=.f6761833-3958-4dce-9b71-b6da81d610cd@github.com>
References: <T_4H65CZfk5uY1pe_ZOBVapPWALQ504zkUVnWHfM3Q4=.f6761833-3958-4dce-9b71-b6da81d610cd@github.com>
Message-ID: <ZLwhn4YIFy0AP6kIhMGvqhPlLQgqe96F30q0qB38XRw=.24808fea-0ba6-4b5a-aff4-9ba894d87237@github.com>

> * Moved to a single bytecode testing API
> * Cleaned out vbytecodes
> * Cleanup of tests not actually using the API
> * Removed TestNativeClone's API usage since cooking the method handle could no
> longer bypass the verifier's bad access check

David Simms has updated the pull request incrementally with one additional commit since the last revision:

  Review comments applied

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/279/files
  - new: https://git.openjdk.java.net/valhalla/pull/279/files/96f29c0f..c7d9c288

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=279&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=279&range=00-01

  Stats: 20 lines in 8 files changed: 0 ins; 4 del; 16 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/279.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/279/head:pull/279

PR: https://git.openjdk.java.net/valhalla/pull/279

From dsimms at openjdk.java.net  Wed Dec  2 10:28:22 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Dec 2020 10:28:22 GMT
Subject: [lworld] RFR: 8231500: [lworld] Merge the experimental bytecode
 API [v2]
In-Reply-To: <1Fb9TjCKecszA_1SeWUw7qJhS3H_amRAeYkE6ZXfOcs=.f5491814-e1a6-40a9-b44f-88265171ab6a@github.com>
References: <T_4H65CZfk5uY1pe_ZOBVapPWALQ504zkUVnWHfM3Q4=.f6761833-3958-4dce-9b71-b6da81d610cd@github.com>
 <1Fb9TjCKecszA_1SeWUw7qJhS3H_amRAeYkE6ZXfOcs=.f5491814-e1a6-40a9-b44f-88265171ab6a@github.com>
Message-ID: <_Yn29Af7S4fvl4m_-3rjVua2J9C9n1qCsSdGT3Z2pyE=.6de2b621-a742-4d28-bb99-f53ea6a9aeed@github.com>

On Tue, 1 Dec 2020 18:16:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> David Simms has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments applied
>
> test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java line 271:
> 
>> 269: 
>> 270:             @Override
>> 271:             public boolean isValue(String desc) {
> 
> I think we should rename `isValue` to `isInlineClass` and also other new `xxxValue` methods

Comments applied

> test/jdk/java/lang/invoke/common/test/java/lang/invoke/lib/InstructionHelper.java line 171:
> 
>> 169:     }
>> 170: 
>> 171:     public static MethodHandle loadCode(MethodHandles.Lookup lookup, String className, String methodName, MethodType type, Consumer<? super MethodHandleCodeBuilder<?>> builder) {
> 
> Are these two `loadCode` methods taking a builder `Consumer` used by the tests?
> 
> If so, the following classes and methods can be made private to hide them as internals.

Comments applied

> test/jdk/lib/testlibrary/bytecode/jdk/experimental/bytecode/BasicTypeHelper.java line 49:
> 
>> 47: 
>> 48:     @Override
>> 49:     public boolean isValue(String t) {
> 
> s/isValue/isInlineClass/

Comments applied

> test/jdk/lib/testlibrary/bytecode/jdk/experimental/bytecode/BasicTypeHelper.java line 59:
> 
>> 57: 
>> 58:     @Override
>> 59:     public String valueType(String s) {
> 
> s/valueType/inlineType/

Comments applied

> test/jdk/lib/testlibrary/bytecode/jdk/experimental/bytecode/BytePoolHelper.java line 341:
> 
>> 339: 
>> 340:     @Override
>> 341:     public int putValueClass(S symbol) {
> 
> s/putValueClass/putInlineClass/

Comments applied

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

PR: https://git.openjdk.java.net/valhalla/pull/279

From dsimms at openjdk.java.net  Wed Dec  2 10:44:08 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Dec 2020 10:44:08 GMT
Subject: [lworld] Integrated: 8231500: [lworld] Merge the experimental
 bytecode API
In-Reply-To: <T_4H65CZfk5uY1pe_ZOBVapPWALQ504zkUVnWHfM3Q4=.f6761833-3958-4dce-9b71-b6da81d610cd@github.com>
References: <T_4H65CZfk5uY1pe_ZOBVapPWALQ504zkUVnWHfM3Q4=.f6761833-3958-4dce-9b71-b6da81d610cd@github.com>
Message-ID: <oAo3NPcQb9Yu1hQY2FuIH0PWV9H9r4gpqdpYwvRaCAw=.a55a031a-f066-4216-8d87-29a4f3feb741@github.com>

On Wed, 25 Nov 2020 11:58:55 GMT, David Simms <dsimms at openjdk.org> wrote:

> * Moved to a single bytecode testing API
> * Cleaned out vbytecodes
> * Cleanup of tests not actually using the API
> * Removed TestNativeClone's API usage since cooking the method handle could no
> longer bypass the verifier's bad access check

This pull request has now been integrated.

Changeset: 972a7518
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/972a7518
Stats:     9330 lines in 65 files changed: 276 ins; 8939 del; 115 mod

8231500: [lworld] Merge the experimental bytecode API

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

PR: https://git.openjdk.java.net/valhalla/pull/279

From forax at univ-mlv.fr  Wed Dec  2 12:18:06 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 2 Dec 2020 13:18:06 +0100 (CET)
Subject: inline record ref projection contains an empty record attribute
Message-ID: <1017263548.2005297.1606911486680.JavaMail.zimbra@u-pem.fr>

Hi all,
using this inline record

public @__inline__ record IntBox(int value) {}

When the compiler generates the ref projection, IntBox$Ref, an empty attribute "Record" is generated which i believe is a mistake.
The ref projection should not contains that attribute at all.

regards,
R?mi

---
Classfile /home/forax/git/transmogrif/target/classes/fr/umlv/transmogrif/IntBox$ref.class
  Last modified Dec 2, 2020; size 222 bytes
  SHA-256 checksum 2ee826fe2e8735044ea2a7f9e766aa101a7786385b5d27291864e7e4d550d6e2
  Compiled from "IntBox.java"
public abstract class fr.umlv.transmogrif.IntBox$ref extends java.lang.Record
  minor version: 0
  major version: 60
  flags: (0x0421) ACC_PUBLIC, ACC_SUPER, ACC_ABSTRACT
  this_class: #1                          // fr/umlv/transmogrif/IntBox$ref
  super_class: #3                         // java/lang/Record
  interfaces: 0, fields: 0, methods: 0, attributes: 4
Constant pool:
   #1 = Class              #2             // fr/umlv/transmogrif/IntBox$ref
   #2 = Utf8               fr/umlv/transmogrif/IntBox$ref
   #3 = Class              #4             // java/lang/Record
   #4 = Utf8               java/lang/Record
   #5 = Utf8               SourceFile
   #6 = Utf8               IntBox.java
   #7 = Utf8               NestMembers
   #8 = Class              #9             // fr/umlv/transmogrif/IntBox
   #9 = Utf8               fr/umlv/transmogrif/IntBox
  #10 = Utf8               Record                                     <------------ oops
  #11 = Utf8               PermittedSubclasses
{
}
SourceFile: "IntBox.java"
NestMembers:
  fr/umlv/transmogrif/IntBox
PermittedSubclasses:
  fr/umlv/transmogrif/IntBox
Record:
[forax at localhost transmogrif]$ javap -private -c -verbose target/classes/fr/umlv/transmogrif/IntBox\$ref.class 
Classfile /home/forax/git/transmogrif/target/classes/fr/umlv/transmogrif/IntBox$ref.class
  Last modified Dec 2, 2020; size 222 bytes
  SHA-256 checksum 2ee826fe2e8735044ea2a7f9e766aa101a7786385b5d27291864e7e4d550d6e2
  Compiled from "IntBox.java"
public abstract class fr.umlv.transmogrif.IntBox$ref extends java.lang.Record
  minor version: 0
  major version: 60
  flags: (0x0421) ACC_PUBLIC, ACC_SUPER, ACC_ABSTRACT
  this_class: #1                          // fr/umlv/transmogrif/IntBox$ref
  super_class: #3                         // java/lang/Record
  interfaces: 0, fields: 0, methods: 0, attributes: 4
Constant pool:
   #1 = Class              #2             // fr/umlv/transmogrif/IntBox$ref
   #2 = Utf8               fr/umlv/transmogrif/IntBox$ref
   #3 = Class              #4             // java/lang/Record
   #4 = Utf8               java/lang/Record
   #5 = Utf8               SourceFile
   #6 = Utf8               IntBox.java
   #7 = Utf8               NestMembers
   #8 = Class              #9             // fr/umlv/transmogrif/IntBox
   #9 = Utf8               fr/umlv/transmogrif/IntBox
  #10 = Utf8               Record
  #11 = Utf8               PermittedSubclasses
{
}
SourceFile: "IntBox.java"
NestMembers:
  fr/umlv/transmogrif/IntBox
PermittedSubclasses:
  fr/umlv/transmogrif/IntBox
Record:                                 <------------------------ oops


From brian.goetz at oracle.com  Wed Dec  2 14:17:24 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 2 Dec 2020 09:17:24 -0500
Subject: Typed variants of primitives
In-Reply-To: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>
References: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>
Message-ID: <7568c12a-376f-797b-e936-4b181f144062@oracle.com>

This generally goes under the name of "restriction types" in the 
literature, where you take a type (e.g., int), restrict its value set 
("zero or one"), and give it a new name ("bit").? This is a form of 
subtyping; the two have the same representation and meaning, but one has 
a value set that is a subset of the other.? (Subtyping implies you can 
freely assign a bit to an int, but would require a conversion (with 
value checking) in the other direction.)

In practice, a problem with restriction types is that they are usually 
domain-specific, and domain-specific types cause friction at boundaries 
between domains.? Lots of libraries deal out ints, but if your library 
wants to deal in non-negative ints, you usually can't just do a straight 
assignment, which means code at the boundary to convert and deal with 
domain failures.? But, this just says that you have to use them in the 
places where they add enough value.

<digression>

Another issue in practice is that in many languages with restriction 
types, there is an element of "trying to have it both ways."? It is 
often harder to reason about the difference between the base type and a 
restriction, because they share some things and not others.? A good 
example here is the Haskell `type` declaration:

 ??? type Name = String

At first, this looks like C's typedef; it defines the type Name to mean 
String, and you can use Name where String is needed, and vice versa.? 
But there's a subtlety here that is not obvious, which is that an 
aliased typed has a _different dictionary for type class witnesses_.? 
(Type classes are like Java's interfaces; witnesses are the 
implementations for a given set of types, which are declares separately 
from the types, and can be thought of as a vtable.)

To make this concrete, suppose we have a type class Printable:

 ??? class Printable t where
 ??????? print :: t -> String

This is like:

 ??? interface Printable<T> {
 ??????? String print();
 ??? }

Instead of declaring "String implements Printable" as we do in Java, we 
declare a witness:

 ??? instance Printable String where
 ??????? print s = ... implementation of print for String ...

Then, in any context that requires printing, when a string is presented, 
this implementation is used.? But ... when we declare an alias, we can 
declare a _different_ witness for Printable Name:

 ??? instance Printable Name where
 ??????? print n = ... different implementation of print for Name ...

so, sometimes Name and String are interchangeable, and sometimes they 
are not!? This looseness on the part of the language requires more 
vigilence on the part of the programmer.? (With great power comes great 
responsibility.)

</digression>

OK, let's come back to Valhalla.? First, let me point out that the "I 
want it to be an int, but just with a restricted value set" may well be 
premature optimization.? You don't actually care that it shares a 
carrier type with 32-bit ints, what you care about is that it can be 
easily and cheaply used where an int is needed.

Suppose we define:

 ??? inline class PositiveInt {
 ??????? private int v;

 ??????? public PositiveInt(int x) {
 ??????????? if (x < 0)
 ??????????????? throw new IllegalArgumentException(...);
 ??????????? this.v = x;
 ?????? }

 ?????? int val() { return v; }
 ??? }

This provides part of the puzzle; while it looks like it would be 
expensive, `new PositiveInt(x)` will JIT down to a value check and a 
32-bit move.? So the "cheap to convert" box is ticked.? But, the other 
weight of boxing is the syntactic weight; `p = new PositiveInt(x)` is a 
mouthful compared to an ordinary assignment.

Let's ignore the existing getYear method for a moment, and pretend that 
you had instead published:

 ??? Year getYear()

where Year is an inline class that encapsulates an int.? Then if the 
user wants an int, they could say:

 ??? int y = date.getYear().val()

But, even that `.val()` might feel like noise; what you're appealing to 
a is a _primitive widening conversion_ (JLS 5.1.2) from Year to int.? 
Since the range of Year is (isomorphic to) a restriction of int, this is 
a reasonable thing to want, that Year could define such a conversion.? 
This would get you to:

 ??? int y = date.getYear()? // implicit primitive widening conversion

We are indeed investigating how we might generalize JLS 5.x to support 
such things.

The other half of your question is whether you can compatibly change the 
already-published method signature.? As John mentioned, we've 
investigated how bridging might be used profitably here.? Java doesn't 
let you overload on return types, and changing this is a big lift (for 
various mostly-accidental reasons.)? But there might be an intermediate 
ground that is still helpful, which is to allow certain changes in 
return type to be source- and binary-compatible.? Ignoring Valhalla for 
a moment, let's say you wanted to change the return type from `int` to 
`long`.? Conveniently there is a primitive widening conversion from int 
to long!? Then it would be source-compatible to change an int-returning 
method to a long-returning one; on recompilation, existing uses would 
just do the widening silently.? To make this binary-compatible, we'd 
also need a way of inserting a bridge method to intercept linkage to the 
old signature and do the int->long adaptation.? (This technique is 
considerably easier for static or final methods than for those that 
might have overrides, but even the latter is theoretically possible, 
just at much higher cost.)? So, such a thing is workable, but clearly 
there's work to do.

TO recap the above: the conditions on when this would be a compatible 
change is when the new return type is "wider" than the old one (and 
ideally, when the method is static or final.) If we could define a 
primitive widening conversion from Year to int, then yes, we could 
migrate the int-returning method to return Year, in a compatible manner, 
and existing int-consumers wouldn't notice the difference.


Very short answer: Yes, this is all being considered!



On 11/29/2020 7:13 PM, Stephen Colebourne wrote:
> I wanted to raise a concept that I don't remember seeing as part of
> the valhalla work so far, and I'll do so via a java.time.* example.
>
>
> `java.time.*` contains a `Year` value-based class that effectively
> acts as a "typed int" with two key purposes:
> - to provide additional type safety if desired for the concept of "year"
> - to restrict the valid int values to -999_999_999 to 999_999_999.
>
> `LocalDate` has a method `getYear()`, but it returns an `int`, rather
> than the `Year` class. Was this a mistake? Not really, it was a
> pragmatic decision to say that most users of the API would want the
> int, not the `Year` value type (and the performance hit of an
> additional object).
>
> In an ideal valhalla world, `LocalDate.getYear()` would be changed to
> return `Year`, not `int`, and this change would be entirely backwards
> compatible. The implication is that a valhalla `Year` value type could
> be freely unboxed to an `int`.
>
>
> Now of course, it is almost certainly pie-in-the-sky to try and make
> something this backwards compatible. But what about new types? In API
> design terms, there is appeal in defining a type that restricts the
> valid set of ints, for example a `PositiveInt` value type. But without
> the associated boxing/unboxing to `int` and maths operator-overloading
> it is generally more pain than it is worth to design an API that way.
> Has this concept been considered?
>
> Stephen


From fparain at openjdk.java.net  Wed Dec  2 14:19:17 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 2 Dec 2020 14:19:17 GMT
Subject: RFR: 8257600: [type-restrictions] Implement RestrictedField in C1
Message-ID: <Vtog3nPM_d5mWmjAfbrQs6d89K_AkhCVI0THwED9lbA=.e2c32fe7-b488-4114-8ccc-1f4712561c42@github.com>

Please review theses changes adding RestrictedField support to C1.
Tests have been added using the annotation added by JDK-8255856.
Tests revealed some issues with the support of RestrictedField in the interpreter, fixes are included in this patch.
The changes also includes some renaming after discussions with Dan.

Thank you,

Fred

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

Commit messages:
 - Re-enable RestrictedType for static fields, minor fixes
 - Reject RestrictedField attribute on static fields
 - Fix tabs
 - Fix interpreter withfield, fix test 5, automated tests
 - More tests
 - Fix InstanceKlass size computation and add test
 - Fix code after RestrictedType model update
 - Merge remote-tracking branch 'upstream/type-restrictions' into restricted_fields_c1
 - Merge remote-tracking branch 'upstream/type-restrictions' into restricted_fields_c1
 - Add checkcasts to write access to restricted fields
 - ... and 1 more: https://git.openjdk.java.net/valhalla/compare/4902cf9c...21ac7562

Changes: https://git.openjdk.java.net/valhalla/pull/288/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=288&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257600
  Stats: 489 lines in 17 files changed: 455 ins; 5 del; 29 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/288.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/288/head:pull/288

PR: https://git.openjdk.java.net/valhalla/pull/288

From brian.goetz at oracle.com  Wed Dec  2 14:31:32 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 2 Dec 2020 09:31:32 -0500
Subject: Typed variants of primitives
In-Reply-To: <CACzrW9CxEJRX6Bka6Lu8an8=gnWPb9rVhZp97KLk46JMaMG4TQ@mail.gmail.com>
References: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>
 <F0FDCFB9-D95D-41EA-A0B6-7DAB199FA1A5@oracle.com>
 <CACzrW9CxEJRX6Bka6Lu8an8=gnWPb9rVhZp97KLk46JMaMG4TQ@mail.gmail.com>
Message-ID: <f899ce6a-78c0-c2fc-4e61-838e8ec94a9d@oracle.com>


> I don't think so, it all looks possible though no doubt very long
> term. The only point I'd note is that Year.default is not a valid
> year, thus more akin to null, but nulls are a whole other topic.

The topic of "inline classes with no good default" is indeed a thorny 
one, and we don't yet have a good set of recommendations here.? Possible 
moves include:

1.? Just don't make it an inline class.
2.? Pick an arbitrary default (Jan 1, 1972.)
3.? Invent a sentinel, try to make using it fail-fast (like a new kind 
of null), and make users check it (which they'll forget to do.)
4.? Use a "reference-default" inline class (one for which the unadorned 
name corresponds to the reference projection), meaning that the default 
value will truly be `null`.

None of these are great, but (4) seems to be the least-bad of the 
options identified so far.? In this world, you declare:

 ??? __mumble_ref_mumble__ inline class Year { ... }

which, like any other inline class declaration, gives rise to three 
types: Year.ref (a true reference type, whose value set consists of 
references to instances of Year, and null), Year.val (whose value set 
consists of instances of Year), and Year.? The only difference is that 
Year becomes an alias for Year.ref rather than Year.val. So:

 ??? Year y = date.getYear()? // might be null

What do you give up?? Well, refs are pointers, so Year is not flattened 
in layout or calling convention.? But Year.val is, so implementations 
can use Year.val for representation, and will get flattening in 
layouts.? It's not ideal, but it's a glass half-full, and the null you 
get is a real null, rather than an ad-hoc one. Work in progress.

> I asked because a question was raised to me as to whether we should
> add method overloads pre-valhalla to certain APIs in java.time.*.
>    current: LocalDate.of(int, int, int)
>    current: LocalDate.of(int, Month, int)
>    add overload in Java 17?: LocalDate.of(Year, Month, int)
>
> I think you'd suggest not to do that, but just want to be sure.

I don't see a problem with such overloads.? There's no situation in 
which overload selection would be confused by the addition of either of 
these (even in the presence of primitive widening conversions from Year 
to int; this would be like overloading m(short) against m(int), which is 
allowed.)

From jesper at selskabet.org  Wed Dec  2 14:54:06 2020
From: jesper at selskabet.org (=?utf-8?Q?Jesper_Steen_M=C3=B8ller?=)
Date: Wed, 2 Dec 2020 15:54:06 +0100
Subject: Typed variants of primitives
In-Reply-To: <f899ce6a-78c0-c2fc-4e61-838e8ec94a9d@oracle.com>
References: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>
 <F0FDCFB9-D95D-41EA-A0B6-7DAB199FA1A5@oracle.com>
 <CACzrW9CxEJRX6Bka6Lu8an8=gnWPb9rVhZp97KLk46JMaMG4TQ@mail.gmail.com>
 <f899ce6a-78c0-c2fc-4e61-838e8ec94a9d@oracle.com>
Message-ID: <72AAB5B4-B4A3-464E-8574-45F3EED87AAC@selskabet.org>

Hi list
> On 2 Dec 2020, at 15.31, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> The topic of "inline classes with no good default" is indeed a thorny one, and we don't yet have a good set of recommendations here.  Possible moves include:

Rhetorically: So why is it really that we need default values for inline classes?

I understand it at the VM level: So that for instance ArrayList<T> eventually can allocate an array of inline T to some capacity, fill it with '.default', and manage the "liveness" of the default values at some higher level, without having to encode the initialized'ness of the array contents.

For raw arrays in Java, there is no "library", which leaves us with "new Year[7]" giving us seven years of tribulation.

So at the VM-level, we need this to do what we want to do.

But at the language-level, couldn't we handle this differently somehow by marking inline classes which have undesirable defaults, and then issuing warnings in case anyone uses it (implicitly or explicitly)?
I do realize you'd still need one of: 

> 2.  Pick an arbitrary default (Jan 1, 1972.)
> 3.  Invent a sentinel, try to make using it fail-fast (like a new kind of null), and make users check it (which they'll forget to do.)

to complete the semantics, but you'd still avoid solutions 1 and 4 and force more code to go through the restricted types "barrier to entry".

For comparison:
C++ and Rust have similar issues.
While they both support types without defaults at the language/type system level, they solve the collection-over-array challenge by trusting the library.

-Jesper


From lfoltan at openjdk.java.net  Wed Dec  2 15:10:09 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Wed, 2 Dec 2020 15:10:09 GMT
Subject: RFR: 8257600: [type-restrictions] Implement RestrictedField in C1
In-Reply-To: <Vtog3nPM_d5mWmjAfbrQs6d89K_AkhCVI0THwED9lbA=.e2c32fe7-b488-4114-8ccc-1f4712561c42@github.com>
References: <Vtog3nPM_d5mWmjAfbrQs6d89K_AkhCVI0THwED9lbA=.e2c32fe7-b488-4114-8ccc-1f4712561c42@github.com>
Message-ID: <NJ2s64EaSUu4BloLKhdBQ0r6olMWM-mr8sRS5Ip5ldw=.0bd9e40b-0394-4fc2-bc91-d02b7520241b@github.com>

On Wed, 2 Dec 2020 14:15:09 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review theses changes adding RestrictedField support to C1.
> Tests have been added using the annotation added by JDK-8255856.
> Tests revealed some issues with the support of RestrictedField in the interpreter, fixes are included in this patch.
> The changes also includes some renaming after discussions with Dan.
> 
> Thank you,
> 
> Fred

The interpreter and class file parsing changes look good.  I left a few minor comments to consider.  I did not review in depth the c1 changes.
Thanks,
Lois

src/hotspot/share/classfile/classFileParser.cpp line 1790:

> 1788:     // as the normal signature for this field (for instance in field access bytecodes) but it also
> 1789:     // has a restricted type that will be used internally by the VM as the real type of the field.
> 1790:     // Current constrains are that the restricted type must be an inline type and the descriptor

Small nit - contrains --> contraints

src/hotspot/share/classfile/classFileParser.cpp line 6778:

> 6776:                                                    Handle(THREAD, _loader_data->class_loader()),
> 6777:                                                    _protection_domain, CHECK);
> 6778:         if (desc_klass == NULL || !klass->is_subtype_of(desc_klass)) {

Consider if using a ResolvingSignatureStream & a call to ResolvingSignatureStream::as_klass() might be a more JVM consistent way to obtain the Klass from the descriptor signature.

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

Marked as reviewed by lfoltan (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/288

From brian.goetz at oracle.com  Wed Dec  2 15:17:21 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 2 Dec 2020 10:17:21 -0500
Subject: Typed variants of primitives
In-Reply-To: <72AAB5B4-B4A3-464E-8574-45F3EED87AAC@selskabet.org>
References: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>
 <F0FDCFB9-D95D-41EA-A0B6-7DAB199FA1A5@oracle.com>
 <CACzrW9CxEJRX6Bka6Lu8an8=gnWPb9rVhZp97KLk46JMaMG4TQ@mail.gmail.com>
 <f899ce6a-78c0-c2fc-4e61-838e8ec94a9d@oracle.com>
 <72AAB5B4-B4A3-464E-8574-45F3EED87AAC@selskabet.org>
Message-ID: <754d3ff1-0f00-062e-59cb-21cc4cfd8231@oracle.com>

You can try, but you can only succeed partially.

The essential problem you are trying to avoid is observing an 
uninitialized variable.? The JVM provides a base level of safety by 
ensuring that if you observe an uninitialized variable (fields and array 
elements), you get a well-defined default (which conveniently happens to 
be all zero bits) rather than whatever garbage bits were left over from 
last night's party. The special reference "null", with its fail-fast 
behavior, is a good default for object references, because if you try to 
use it, you find out quickly.

Languages can try to make this harder, but beyond a certain point, each 
additional increment gets expensive (e.g., should we try to prevent the 
default value from being observed through a data race?)

For example, we already require final fields to be DU at the end of the 
constructor.? We could engage a similar sort of type checking for fields 
of inline classes that have no good default, but (a) this might be too 
restrictive, (b) what about data races, and (c) it doesn't give us much 
to solve the harder problem which is arrays.

But we can't ban arrays of NGDV inlines; ArrayList needs them. So "trust 
the library" quickly degenerates to "trust everyone", which is to say: 
pick 1972 as the default, and let the chips fall where they may.? This 
is doable, but not so great.





On 12/2/2020 9:54 AM, Jesper Steen M?ller wrote:
> Hi list
>> On 2 Dec 2020, at 15.31, Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>> The topic of "inline classes with no good default" is indeed a thorny one, and we don't yet have a good set of recommendations here.  Possible moves include:
> Rhetorically: So why is it really that we need default values for inline classes?
>
> I understand it at the VM level: So that for instance ArrayList<T> eventually can allocate an array of inline T to some capacity, fill it with '.default', and manage the "liveness" of the default values at some higher level, without having to encode the initialized'ness of the array contents.
>
> For raw arrays in Java, there is no "library", which leaves us with "new Year[7]" giving us seven years of tribulation.
>
> So at the VM-level, we need this to do what we want to do.
>
> But at the language-level, couldn't we handle this differently somehow by marking inline classes which have undesirable defaults, and then issuing warnings in case anyone uses it (implicitly or explicitly)?
> I do realize you'd still need one of:
>
>> 2.  Pick an arbitrary default (Jan 1, 1972.)
>> 3.  Invent a sentinel, try to make using it fail-fast (like a new kind of null), and make users check it (which they'll forget to do.)
> to complete the semantics, but you'd still avoid solutions 1 and 4 and force more code to go through the restricted types "barrier to entry".
>
> For comparison:
> C++ and Rust have similar issues.
> While they both support types without defaults at the language/type system level, they solve the collection-over-array challenge by trusting the library.
>
> -Jesper
>


From github.com+828220+forax at openjdk.java.net  Wed Dec  2 14:44:03 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 2 Dec 2020 14:44:03 GMT
Subject: RFR: 8257600: [type-restrictions] Implement RestrictedField in C1
In-Reply-To: <Vtog3nPM_d5mWmjAfbrQs6d89K_AkhCVI0THwED9lbA=.e2c32fe7-b488-4114-8ccc-1f4712561c42@github.com>
References: <Vtog3nPM_d5mWmjAfbrQs6d89K_AkhCVI0THwED9lbA=.e2c32fe7-b488-4114-8ccc-1f4712561c42@github.com>
Message-ID: <5pZPS_BYAPD7F38NGVSXlLHPHkFC972efk1bvwken8E=.525788b8-8457-43f7-b377-236d50fe65d9@github.com>

On Wed, 2 Dec 2020 14:15:09 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review theses changes adding RestrictedField support to C1.
> Tests have been added using the annotation added by JDK-8255856.
> Tests revealed some issues with the support of RestrictedField in the interpreter, fixes are included in this patch.
> The changes also includes some renaming after discussions with Dan.
> 
> Thank you,
> 
> Fred

Hi,
the requirement that a restricted type must be an inline type is too strong,
the restricted type should be able to be at least the same as the field descriptor too otherwise you can not using it in a template class if the argument type is not an inline class.

And for other languages than Java that may want to support full reification, it's better to support any subtypes.

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

PR: https://git.openjdk.java.net/valhalla/pull/288

From jesper at selskabet.org  Wed Dec  2 15:29:08 2020
From: jesper at selskabet.org (=?utf-8?Q?Jesper_Steen_M=C3=B8ller?=)
Date: Wed, 2 Dec 2020 16:29:08 +0100
Subject: Typed variants of primitives
In-Reply-To: <754d3ff1-0f00-062e-59cb-21cc4cfd8231@oracle.com>
References: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>
 <F0FDCFB9-D95D-41EA-A0B6-7DAB199FA1A5@oracle.com>
 <CACzrW9CxEJRX6Bka6Lu8an8=gnWPb9rVhZp97KLk46JMaMG4TQ@mail.gmail.com>
 <f899ce6a-78c0-c2fc-4e61-838e8ec94a9d@oracle.com>
 <72AAB5B4-B4A3-464E-8574-45F3EED87AAC@selskabet.org>
 <754d3ff1-0f00-062e-59cb-21cc4cfd8231@oracle.com>
Message-ID: <2ECE139E-39C1-41D1-9224-3AEABBBEAE7B@selskabet.org>


> On 2 Dec 2020, at 16.17, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> You can try, but you can only succeed partially.  
> 
> The essential problem you are trying to avoid is observing an uninitialized variable.  The JVM provides a base level of safety by ensuring that if you observe an uninitialized variable (fields and array elements), you get a well-defined default (which conveniently happens to be all zero bits) rather than whatever garbage bits were left over from last night's party.  The special reference "null", with its fail-fast behavior, is a good default for object references, because if you try to use it, you find out quickly.  
> 
> Languages can try to make this harder, but beyond a certain point, each additional increment gets expensive (e.g., should we try to prevent the default value from being observed through a data race?)  
> 

Agreed. And since we can't avoid tearing without a heavy overhead, we probably shouldn't bother with the data race either.


> For example, we already require final fields to be DU at the end of the constructor.  We could engage a similar sort of type checking for fields of inline classes that have no good default, but (a) this might be too restrictive, (b) what about data races, and (c) it doesn't give us much to solve the harder problem which is arrays.  
> 
> But we can't ban arrays of NGDV inlines; ArrayList needs them.  So "trust the library" quickly degenerates to "trust everyone", which is to say: pick 1972 as the default, and let the chips fall where they may.  This is doable, but not so great.  
> 

Doable is good - and even better with a way do specify "don't do this" where we can: You can restrict access to a default constructor, or deprecate it. Could we do something similar with .default?

-Jesper



From thartmann at openjdk.java.net  Wed Dec  2 15:33:09 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 2 Dec 2020 15:33:09 GMT
Subject: RFR: 8257600: [type-restrictions] Implement RestrictedField in C1
In-Reply-To: <Vtog3nPM_d5mWmjAfbrQs6d89K_AkhCVI0THwED9lbA=.e2c32fe7-b488-4114-8ccc-1f4712561c42@github.com>
References: <Vtog3nPM_d5mWmjAfbrQs6d89K_AkhCVI0THwED9lbA=.e2c32fe7-b488-4114-8ccc-1f4712561c42@github.com>
Message-ID: <QDWqiIaQ3Mw6cBFACW2zS5tTdvnWhgQpzU0MWKAW84k=.7a2d3ffa-ccb5-4ee8-a494-ceed5e1f01bd@github.com>

On Wed, 2 Dec 2020 14:15:09 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review theses changes adding RestrictedField support to C1.
> Tests have been added using the annotation added by JDK-8255856.
> Tests revealed some issues with the support of RestrictedField in the interpreter, fixes are included in this patch.
> The changes also includes some renaming after discussions with Dan.
> 
> Thank you,
> 
> Fred

Compiler changes look good to me!

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

Marked as reviewed by thartmann (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/288

From fparain at openjdk.java.net  Wed Dec  2 15:50:19 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 2 Dec 2020 15:50:19 GMT
Subject: RFR: 8257600: [type-restrictions] Implement RestrictedField in C1
 [v2]
In-Reply-To: <Vtog3nPM_d5mWmjAfbrQs6d89K_AkhCVI0THwED9lbA=.e2c32fe7-b488-4114-8ccc-1f4712561c42@github.com>
References: <Vtog3nPM_d5mWmjAfbrQs6d89K_AkhCVI0THwED9lbA=.e2c32fe7-b488-4114-8ccc-1f4712561c42@github.com>
Message-ID: <fw_PgzMXBqOtTgIGhxS1_nGEemf5HSRhZXuiN5-A3hI=.b908139e-defb-4170-a16a-267ce056f67d@github.com>

> Please review theses changes adding RestrictedField support to C1.
> Tests have been added using the annotation added by JDK-8255856.
> Tests revealed some issues with the support of RestrictedField in the interpreter, fixes are included in this patch.
> The changes also includes some renaming after discussions with Dan.
> 
> Thank you,
> 
> Fred

Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:

  Address Lois' comments

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/288/files
  - new: https://git.openjdk.java.net/valhalla/pull/288/files/21ac7562..b7f90437

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=288&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=288&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/288.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/288/head:pull/288

PR: https://git.openjdk.java.net/valhalla/pull/288

From sergey.kuksenko at oracle.com  Wed Dec  2 15:52:07 2020
From: sergey.kuksenko at oracle.com (Sergey Kuksenko)
Date: Wed, 2 Dec 2020 07:52:07 -0800 (PST)
Subject: UseACmpProfile question.
In-Reply-To: <87czzsjzkt.fsf@redhat.com>
References: <6e54062d-a9f4-6a03-9d41-ec37ea658bc6@oracle.com>
 <87tutekjcd.fsf@redhat.com> <defc557b-d6d4-c116-d9d3-79ad58a327da@oracle.com>
 <87im9sjm5v.fsf@redhat.com> <1fdf6f43-f542-a7f8-b510-413c679b111a@oracle.com>
 <87czzsjzkt.fsf@redhat.com>
Message-ID: <d3415b45-8b67-5ee4-5c78-ce83e1f448e2@oracle.com>

Yes. Covering array profile is in my TODO list, just not done yet.

Also I realized that all my existing benchmarks are single typed. I have 
to run it with and without profiles. Are options -XX:-UseACmpProfile 
-XX:-UseTypeSpeculation -XX:-UseArrayLoadStoreProfile enough to turn off 
all profiling?


On 12/2/20 2:02 AM, Roland Westrelin wrote:
>> Looks like acmp profiling performance results are transforming from a
>> simple email to a large report. Need time to process all scenarios.
> Great. What about aaload/aastore profiling? I think you said before that
> there are scenarios where that profiling helps quite a bit. We try hard
> to perform well when profile data is not available. That that profiling
> helps that much may be a sign that we could do better when it's
> unavailable. I think it would be helpful if we could take a look at
> those cases.
>
> Roland.
>

From dsimms at openjdk.java.net  Wed Dec  2 15:54:12 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Dec 2020 15:54:12 GMT
Subject: [lworld] RFR: Remove deprecated options from tests
Message-ID: <slqOUHjrsZWfzmkx2ToKeB3twgpz52n1IcXIu9HVMKA=.952c8e36-0689-4684-bd18-241d3891acaa@github.com>

* UseBiasedLocking
* UseOptoBiasInlining

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

Commit messages:
 - Remove deprecated options from tests

Changes: https://git.openjdk.java.net/valhalla/pull/289/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=289&range=00
  Stats: 8 lines in 2 files changed: 0 ins; 3 del; 5 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/289.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/289/head:pull/289

PR: https://git.openjdk.java.net/valhalla/pull/289

From lfoltan at openjdk.java.net  Wed Dec  2 16:01:10 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Wed, 2 Dec 2020 16:01:10 GMT
Subject: [lworld] RFR: Remove deprecated options from tests
In-Reply-To: <slqOUHjrsZWfzmkx2ToKeB3twgpz52n1IcXIu9HVMKA=.952c8e36-0689-4684-bd18-241d3891acaa@github.com>
References: <slqOUHjrsZWfzmkx2ToKeB3twgpz52n1IcXIu9HVMKA=.952c8e36-0689-4684-bd18-241d3891acaa@github.com>
Message-ID: <exodkcRLK4yRVYrEyOeXWywXLpQxusUGWFnJB5-rCmI=.2b3f23d9-101e-4956-950c-5a541598d34b@github.com>

On Wed, 2 Dec 2020 15:49:47 GMT, David Simms <dsimms at openjdk.org> wrote:

> * UseBiasedLocking
> * UseOptoBiasInlining

Looks good.

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

Marked as reviewed by lfoltan (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/289

From thartmann at openjdk.java.net  Wed Dec  2 16:01:10 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 2 Dec 2020 16:01:10 GMT
Subject: [lworld] RFR: Remove deprecated options from tests
In-Reply-To: <slqOUHjrsZWfzmkx2ToKeB3twgpz52n1IcXIu9HVMKA=.952c8e36-0689-4684-bd18-241d3891acaa@github.com>
References: <slqOUHjrsZWfzmkx2ToKeB3twgpz52n1IcXIu9HVMKA=.952c8e36-0689-4684-bd18-241d3891acaa@github.com>
Message-ID: <fF8qKMzndKu48qezylhVad1XljZ1iV-BLhfc79cHg_w=.f1ba6182-8d61-45df-993f-44e299aeadbb@github.com>

On Wed, 2 Dec 2020 15:49:47 GMT, David Simms <dsimms at openjdk.org> wrote:

> * UseBiasedLocking
> * UseOptoBiasInlining

Marked as reviewed by thartmann (Committer).

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

PR: https://git.openjdk.java.net/valhalla/pull/289

From dsimms at openjdk.java.net  Wed Dec  2 16:33:11 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Wed, 2 Dec 2020 16:33:11 GMT
Subject: [lworld] Integrated: Remove deprecated options from tests
In-Reply-To: <slqOUHjrsZWfzmkx2ToKeB3twgpz52n1IcXIu9HVMKA=.952c8e36-0689-4684-bd18-241d3891acaa@github.com>
References: <slqOUHjrsZWfzmkx2ToKeB3twgpz52n1IcXIu9HVMKA=.952c8e36-0689-4684-bd18-241d3891acaa@github.com>
Message-ID: <_HfRhZRs4vmjrE36iOp7MB38rglDUZVo-0y3qqa_bHw=.647fd312-b39b-40c7-b2a9-75930bf3d260@github.com>

On Wed, 2 Dec 2020 15:49:47 GMT, David Simms <dsimms at openjdk.org> wrote:

> * UseBiasedLocking
> * UseOptoBiasInlining

This pull request has now been integrated.

Changeset: c08bc913
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/c08bc913
Stats:     8 lines in 2 files changed: 0 ins; 3 del; 5 mod

Remove deprecated options from tests

Reviewed-by: thartmann, lfoltan

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

PR: https://git.openjdk.java.net/valhalla/pull/289

From scolebourne at joda.org  Wed Dec  2 22:57:46 2020
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 2 Dec 2020 22:57:46 +0000
Subject: Typed variants of primitives
In-Reply-To: <7568c12a-376f-797b-e936-4b181f144062@oracle.com>
References: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>
 <7568c12a-376f-797b-e936-4b181f144062@oracle.com>
Message-ID: <CACzrW9AFHxnWwvVenQwHc5NhOZz6FpPbsYYMcTj572M9H0RW=w@mail.gmail.com>

On Wed, 2 Dec 2020 at 14:17, Brian Goetz <brian.goetz at oracle.com> wrote:
> Then if the user wants an int, they could say:
>
>     int y = date.getYear().val()
>
> But, even that `.val()` might feel like noise; what you're appealing to a is a _primitive widening conversion_ (JLS 5.1.2) from Year to int.  Since the range of Year is (isomorphic to) a restriction of int, this is a reasonable thing to want, that Year could define such a conversion.  This would get you to:
>
>     int y = date.getYear()  // implicit primitive widening conversion
>
> We are indeed investigating how we might generalize JLS 5.x to support such things.
...
> Very short answer: Yes, this is all being considered!

Great!


> On 11/29/2020 7:13 PM, Stephen Colebourne wrote:
>
> I wanted to raise a concept that I don't remember seeing as part of
> the valhalla work so far, and I'll do so via a java.time.* example.
>
>
> `java.time.*` contains a `Year` value-based class that effectively
> acts as a "typed int" with two key purposes:
> - to provide additional type safety if desired for the concept of "year"
> - to restrict the valid int values to -999_999_999 to 999_999_999.
>
> `LocalDate` has a method `getYear()`, but it returns an `int`, rather
> than the `Year` class. Was this a mistake? Not really, it was a
> pragmatic decision to say that most users of the API would want the
> int, not the `Year` value type (and the performance hit of an
> additional object).
>
> In an ideal valhalla world, `LocalDate.getYear()` would be changed to
> return `Year`, not `int`, and this change would be entirely backwards
> compatible. The implication is that a valhalla `Year` value type could
> be freely unboxed to an `int`.
>
>
> Now of course, it is almost certainly pie-in-the-sky to try and make
> something this backwards compatible. But what about new types? In API
> design terms, there is appeal in defining a type that restricts the
> valid set of ints, for example a `PositiveInt` value type. But without
> the associated boxing/unboxing to `int` and maths operator-overloading
> it is generally more pain than it is worth to design an API that way.
> Has this concept been considered?
>
> Stephen
>
>

From scolebourne at joda.org  Thu Dec  3 01:02:06 2020
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 3 Dec 2020 01:02:06 +0000
Subject: Embrace nulls, was Re: Typed variants of primitives
In-Reply-To: <f899ce6a-78c0-c2fc-4e61-838e8ec94a9d@oracle.com>
References: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>
 <F0FDCFB9-D95D-41EA-A0B6-7DAB199FA1A5@oracle.com>
 <CACzrW9CxEJRX6Bka6Lu8an8=gnWPb9rVhZp97KLk46JMaMG4TQ@mail.gmail.com>
 <f899ce6a-78c0-c2fc-4e61-838e8ec94a9d@oracle.com>
Message-ID: <CACzrW9DGDm2k68Q7Bo6puRgbxqsfrTN0Detk0GDbafpjhCnsng@mail.gmail.com>

Oops, my throwaway comment on nulls has ended up in a thread...

Anyway, I've been meaning to throw an observation about nulls out for
a few weeks: In recent language/library changes there has been a
pushback to block or restrict null (streams, switch, patterns, etc),
which eventually was rejected with a mantra of "embrace nulls"
instead. Perhaps that same mantra of embracing nulls needs to be
adopted by valhalla?

By embracing nulls, I mean that valhalla could actively seek to ensure
*every* value type has an associated first-class null form. Even those
like int128. And without trying to hide the null under the carpet as
the current reference type approach does (with the side effect of
ruining the potential performance benefits by not flattening in many
cases). Instead of null being an enemy to be dealt with, why not treat
it as a welcome and useful friend?

Group 1: Many potential value types have a spare bit pattern (eg.
LocalDate). Asking them to arrange their bits so that all-zeroes is
not used internally seems like an acceptable trade-off for the
performance benefits. (I'm sure you've already explored mechanisms and
syntaxes to do this). Group 1 would have just one exposed type, which
would be nullable, avoiding the meaningless default problem (no
LocalDate.val).

Group 2: For those value types that do not have a spare bit pattern,
one would need to be added. This is the real "embrace nulls" moment,
and I understand the pain of potentially forcing an Int128 class to
take up 192 bits in memory. I do think it will rarely actually happen
in practice though (see group 3). Group 2 is really just the same as
group 1 but with wasteful memory usage, with one exposed nullable
type.

Group 3:  Most of the cases where there is no spare bit pattern are
also cases where there is an acceptable zero value. This is where
having two exposed types is actually useful, a nullable one and a
non-nullable one, typically with the nullable one needing more bits in
memory. The good name (Int128) would always go to the nullable form
and the other name (Int128.val or int128) would go to the
primitive-like zero-by-default form.

I also think this reduces the schism between valhalla types and
reference-like. All new and migrated value types (eg Int128, Optional,
LocalDate) would be UpperCamelCase and nullable, just like reference
types. The remaining points of difference around identity (==,
synchronization, etc) are generally less observable by developers.
Forcing use-site opt-in to the real valhalla primitives (Int128.val or
int128 or vInt128) would make it more obvious and visible to code
readers that these types are more primitive-like.

I think this could be allocated number 5 on your list. It embraces
nulls because it flips valhalla on its head by focussing on making
everything nullable, with primitive-like values as an optimisation. It
doesn't treat the primitive-like value types as the real deal and
nullability as an after-thought, it does the exact opposite where
nullable value types are the norm and primitive-like ones are
special/weird.

BTW I don't think developers will forget to check for null any more
than they do today - these new nullable value types won't look or
behave that differently to regular reference types wrt null. (And if
not checking for null is a problem, it should be fixed with holistic
nullable type tracking across references and values anyway.)

Summary of an "embrace nulls" approach:
- All value types have a standard form that is always nullable (embrace nulls)
- The standard form has an UpperCamelCase name
- Value type authors must ensure the all-zeroes bit pattern is not
used, and must add an extra "useless" field if necessary
- Value type authors can optionally choose to declare a second
non-nullable type where all-zeroes is given meaning (eg. zero)
- If they do, the second form always gets a non-standard name, eg
(Int128.val or int128 or vInt128)
- Both forms of value type would be fully flattenable

thanks
Stephen


On Wed, 2 Dec 2020 at 14:33, Brian Goetz <brian.goetz at oracle.com> wrote:
> > I don't think so, it all looks possible though no doubt very long
> > term. The only point I'd note is that Year.default is not a valid
> > year, thus more akin to null, but nulls are a whole other topic.
>
> The topic of "inline classes with no good default" is indeed a thorny
> one, and we don't yet have a good set of recommendations here.  Possible
> moves include:
>
> 1.  Just don't make it an inline class.
> 2.  Pick an arbitrary default (Jan 1, 1972.)
> 3.  Invent a sentinel, try to make using it fail-fast (like a new kind
> of null), and make users check it (which they'll forget to do.)
> 4.  Use a "reference-default" inline class (one for which the unadorned
> name corresponds to the reference projection), meaning that the default
> value will truly be `null`.
>
> None of these are great, but (4) seems to be the least-bad of the
> options identified so far.  In this world, you declare:
>
>      __mumble_ref_mumble__ inline class Year { ... }
>
> which, like any other inline class declaration, gives rise to three
> types: Year.ref (a true reference type, whose value set consists of
> references to instances of Year, and null), Year.val (whose value set
> consists of instances of Year), and Year.  The only difference is that
> Year becomes an alias for Year.ref rather than Year.val. So:
>
>      Year y = date.getYear()  // might be null
>
> What do you give up?  Well, refs are pointers, so Year is not flattened
> in layout or calling convention.  But Year.val is, so implementations
> can use Year.val for representation, and will get flattening in
> layouts.  It's not ideal, but it's a glass half-full, and the null you
> get is a real null, rather than an ad-hoc one. Work in progress.

From dsimms at openjdk.java.net  Thu Dec  3 06:59:01 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 3 Dec 2020 06:59:01 GMT
Subject: [lworld] RFR: Merge jdk
Message-ID: <xjSIEPdDIN8yG0ysqQ4c2QP-OftX_qSiKnCmZLPqLWk=.40414cc7-2314-4271-8370-6f564a03c1e6@github.com>

Merge tag 'jdk-16+27'

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

Commit messages:
 - Logical merge fixes for compilation
 - Merge tag 'jdk-16+27' into lworld_merge_jdk_16_27
 - 8256818: SSLSocket that is never bound or connected leaks socket resources
 - 8257189: Handle concurrent updates of MH.form better
 - 8257565: epsilonBarrierSet.hpp should not include barrierSetAssembler
 - 8256256: UL should not use heap allocation for output string
 - 8257140: Crash in JvmtiTagMap::flush_object_free_events()
 - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64
 - 8254877: GCLogPrecious::_lock rank constrains what locks you are allowed to have when crashing
 - 8256382: Use try_lock for hs_err EventLog printing
 - ... and 109 more: https://git.openjdk.java.net/valhalla/compare/c08bc913...fe42dcfb

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - lworld: https://webrevs.openjdk.java.net/?repo=valhalla&pr=290&range=00.0
 - jdk: https://webrevs.openjdk.java.net/?repo=valhalla&pr=290&range=00.1

Changes: https://git.openjdk.java.net/valhalla/pull/290/files
  Stats: 25036 lines in 607 files changed: 13883 ins; 3564 del; 7589 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/290.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/290/head:pull/290

PR: https://git.openjdk.java.net/valhalla/pull/290

From dsimms at openjdk.java.net  Thu Dec  3 07:46:45 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 3 Dec 2020 07:46:45 GMT
Subject: [lworld] RFR: Merge jdk [v2]
In-Reply-To: <xjSIEPdDIN8yG0ysqQ4c2QP-OftX_qSiKnCmZLPqLWk=.40414cc7-2314-4271-8370-6f564a03c1e6@github.com>
References: <xjSIEPdDIN8yG0ysqQ4c2QP-OftX_qSiKnCmZLPqLWk=.40414cc7-2314-4271-8370-6f564a03c1e6@github.com>
Message-ID: <n2RUxlnKOURZ7pdfMnRZorhy_JF6Jq_2V3yLlU_Tx3Q=.f52c1d6c-487c-4889-8b5c-d7262525f9ef@github.com>

> Merge tag 'jdk-16+27'

David Simms has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 1057 commits:

 - Logical merge fixes for compilation
 - Merge tag 'jdk-16+27' into lworld_merge_jdk_16_27
   
   Added tag jdk-16+27 for changeset 93b6ab56
   
   # Conflicts:
   #	src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
   #	src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
   #	src/hotspot/share/opto/output.cpp
   #	src/hotspot/share/opto/subnode.hpp
   #	src/hotspot/share/opto/type.cpp
   #	src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
 - Remove deprecated options from tests
   
   Reviewed-by: thartmann, lfoltan
 - 8231500: [lworld] Merge the experimental bytecode API
 - 8257422: [lworld] Problems with scalarized inline type return and incremental inlining
 - Merge jdk
   
   Merge tag 'jdk-16+26'
 - [lworld] Missed disabling testcase that does not pack well with  -XX:ForceNonTearable
 - 8257446: [lworld] VM flag PrintInlineLayout doesn't work anymore
   
   Reviewed-by: hseigel
 - 8257166: [lworld] CCP fails to optimize FlatArrayCheckNode
 - 8251966: [lworld] TestArrays.java fails with -XX:+ExpandSubTypeCheckAtParseTime
 - ... and 1047 more: https://git.openjdk.java.net/valhalla/compare/93b6ab56...fe42dcfb

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

Changes: https://git.openjdk.java.net/valhalla/pull/290/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=290&range=01
  Stats: 144111 lines in 1307 files changed: 137036 ins; 2527 del; 4548 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/290.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/290/head:pull/290

PR: https://git.openjdk.java.net/valhalla/pull/290

From dsimms at openjdk.java.net  Thu Dec  3 07:46:48 2020
From: dsimms at openjdk.java.net (David Simms)
Date: Thu, 3 Dec 2020 07:46:48 GMT
Subject: [lworld] Integrated: Merge jdk
In-Reply-To: <xjSIEPdDIN8yG0ysqQ4c2QP-OftX_qSiKnCmZLPqLWk=.40414cc7-2314-4271-8370-6f564a03c1e6@github.com>
References: <xjSIEPdDIN8yG0ysqQ4c2QP-OftX_qSiKnCmZLPqLWk=.40414cc7-2314-4271-8370-6f564a03c1e6@github.com>
Message-ID: <I0ikM49g7XV1RipBu6wPcc8DdZ5jO1_NUbfPrm7cqk0=.2060cc08-c780-4c3b-bcdb-28b936ab2c9a@github.com>

On Thu, 3 Dec 2020 06:52:30 GMT, David Simms <dsimms at openjdk.org> wrote:

> Merge tag 'jdk-16+27'

This pull request has now been integrated.

Changeset: 2e71ef66
Author:    David Simms <dsimms at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/2e71ef66
Stats:     25036 lines in 607 files changed: 13883 ins; 3564 del; 7589 mod

Merge jdk

Merge tag 'jdk-16+27'

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

PR: https://git.openjdk.java.net/valhalla/pull/290

From rwestrel at redhat.com  Thu Dec  3 09:29:55 2020
From: rwestrel at redhat.com (Roland Westrelin)
Date: Thu, 03 Dec 2020 10:29:55 +0100
Subject: UseACmpProfile question.
In-Reply-To: <d3415b45-8b67-5ee4-5c78-ce83e1f448e2@oracle.com>
References: <6e54062d-a9f4-6a03-9d41-ec37ea658bc6@oracle.com>
 <87tutekjcd.fsf@redhat.com>
 <defc557b-d6d4-c116-d9d3-79ad58a327da@oracle.com>
 <87im9sjm5v.fsf@redhat.com>
 <1fdf6f43-f542-a7f8-b510-413c679b111a@oracle.com>
 <87czzsjzkt.fsf@redhat.com>
 <d3415b45-8b67-5ee4-5c78-ce83e1f448e2@oracle.com>
Message-ID: <87y2ifi6ek.fsf@redhat.com>


> Also I realized that all my existing benchmarks are single typed. I have 
> to run it with and without profiles. Are options -XX:-UseACmpProfile 
> -XX:-UseTypeSpeculation -XX:-UseArrayLoadStoreProfile enough to turn off 
> all profiling?

Yes it should.

Roland.


From thartmann at openjdk.java.net  Thu Dec  3 09:34:23 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 3 Dec 2020 09:34:23 GMT
Subject: [lworld] Integrated: 8257657: [lworld] TestLWorld and
 TestNullableInlineTypes fail during IR verification
Message-ID: <ZJzCK6iBC4XUpr0hfC0jl9oLTLZW5SRshoWYkM0ESBI=.536e04e8-5a69-4ce9-be6d-9b0289e1f22e@github.com>

https://github.com/openjdk/valhalla/pull/289 removed some deprecated flags from the test scenarios and accidentally changed the extra flags for the default scenarios leading to failures in IR verification (due to different flag settings).

Thanks,
Tobias

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

Commit messages:
 - 8257657: [lworld] TestLWorld and TestNullableInlineTypes fail during IR verification

Changes: https://git.openjdk.java.net/valhalla/pull/291/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=291&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257657
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/291.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/291/head:pull/291

PR: https://git.openjdk.java.net/valhalla/pull/291

From thartmann at openjdk.java.net  Thu Dec  3 09:34:23 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 3 Dec 2020 09:34:23 GMT
Subject: [lworld] Integrated: 8257657: [lworld] TestLWorld and
 TestNullableInlineTypes fail during IR verification
In-Reply-To: <ZJzCK6iBC4XUpr0hfC0jl9oLTLZW5SRshoWYkM0ESBI=.536e04e8-5a69-4ce9-be6d-9b0289e1f22e@github.com>
References: <ZJzCK6iBC4XUpr0hfC0jl9oLTLZW5SRshoWYkM0ESBI=.536e04e8-5a69-4ce9-be6d-9b0289e1f22e@github.com>
Message-ID: <MeQEK8VH2wI4X3Jp34apA7K6A4eOeSlHnKUTMPPB1-k=.a21717d8-3508-43f8-8d84-3a0b46a41b78@github.com>

On Thu, 3 Dec 2020 09:26:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> https://github.com/openjdk/valhalla/pull/289 removed some deprecated flags from the test scenarios and accidentally changed the extra flags for the default scenarios leading to failures in IR verification (due to different flag settings).
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 8408e305
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/8408e305
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8257657: [lworld] TestLWorld and TestNullableInlineTypes fail during IR verification

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

PR: https://git.openjdk.java.net/valhalla/pull/291

From thartmann at openjdk.java.net  Thu Dec  3 13:28:15 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 3 Dec 2020 13:28:15 GMT
Subject: [lworld] Integrated: 8257674: [lworld] C1's substitutability check
 does not respect UseCompressedClassPointers
Message-ID: <ue6s4uZE-Yue08ZvNOGVfV91Hk4dzpbhc_9Mzr3nDZw=.24eba463-9ec1-4b3b-a8f4-f05a26a23cdd@github.com>

`UseCompressedOops` is used instead of `UseCompressedClassPointers` when loading the klass pointers in C1's substitutability check. This explains several intermittent test failures.

Thanks,
Tobias

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

Commit messages:
 - 8257674: [lworld] C1's substitutability does not respect UseCompressedClassPointers

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

PR: https://git.openjdk.java.net/valhalla/pull/292

From thartmann at openjdk.java.net  Thu Dec  3 13:28:15 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 3 Dec 2020 13:28:15 GMT
Subject: [lworld] Integrated: 8257674: [lworld] C1's substitutability check
 does not respect UseCompressedClassPointers
In-Reply-To: <ue6s4uZE-Yue08ZvNOGVfV91Hk4dzpbhc_9Mzr3nDZw=.24eba463-9ec1-4b3b-a8f4-f05a26a23cdd@github.com>
References: <ue6s4uZE-Yue08ZvNOGVfV91Hk4dzpbhc_9Mzr3nDZw=.24eba463-9ec1-4b3b-a8f4-f05a26a23cdd@github.com>
Message-ID: <r2j6qtavYnibTATBLUUIjk4_l2BmC3XMURLzUGeFmB8=.f8f74441-e74d-45ba-8f76-5205ab9c6d68@github.com>

On Thu, 3 Dec 2020 13:23:07 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> `UseCompressedOops` is used instead of `UseCompressedClassPointers` when loading the klass pointers in C1's substitutability check. This explains several intermittent test failures.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 330f2f29
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/330f2f29
Stats:     3 lines in 2 files changed: 0 ins; 2 del; 1 mod

8257674: [lworld] C1's substitutability check does not respect UseCompressedClassPointers

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

PR: https://git.openjdk.java.net/valhalla/pull/292

From fparain at openjdk.java.net  Thu Dec  3 15:19:10 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 3 Dec 2020 15:19:10 GMT
Subject: RFR: 8257600: [type-restrictions] Implement RestrictedField in C1
 [v2]
In-Reply-To: <QDWqiIaQ3Mw6cBFACW2zS5tTdvnWhgQpzU0MWKAW84k=.7a2d3ffa-ccb5-4ee8-a494-ceed5e1f01bd@github.com>
References: <Vtog3nPM_d5mWmjAfbrQs6d89K_AkhCVI0THwED9lbA=.e2c32fe7-b488-4114-8ccc-1f4712561c42@github.com>
 <QDWqiIaQ3Mw6cBFACW2zS5tTdvnWhgQpzU0MWKAW84k=.7a2d3ffa-ccb5-4ee8-a494-ceed5e1f01bd@github.com>
Message-ID: <C1ZMDpKe3JhTdBYMd1a4vbtdAQ5LIqKG1I_SO3oTkm0=.eff37c15-6858-45b9-91ba-9c6976ce385c@github.com>

On Wed, 2 Dec 2020 15:29:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Frederic Parain has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address Lois' comments
>
> Compiler changes look good to me!

Lois, Tobias,

thank you for your reviews.
Lois' comments have been addressed in the latest commit.

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

PR: https://git.openjdk.java.net/valhalla/pull/288

From fparain at openjdk.java.net  Thu Dec  3 15:33:08 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 3 Dec 2020 15:33:08 GMT
Subject: RFR: 8257600: [type-restrictions] Implement RestrictedField in C1
 [v2]
In-Reply-To: <C1ZMDpKe3JhTdBYMd1a4vbtdAQ5LIqKG1I_SO3oTkm0=.eff37c15-6858-45b9-91ba-9c6976ce385c@github.com>
References: <Vtog3nPM_d5mWmjAfbrQs6d89K_AkhCVI0THwED9lbA=.e2c32fe7-b488-4114-8ccc-1f4712561c42@github.com>
 <QDWqiIaQ3Mw6cBFACW2zS5tTdvnWhgQpzU0MWKAW84k=.7a2d3ffa-ccb5-4ee8-a494-ceed5e1f01bd@github.com>
 <C1ZMDpKe3JhTdBYMd1a4vbtdAQ5LIqKG1I_SO3oTkm0=.eff37c15-6858-45b9-91ba-9c6976ce385c@github.com>
Message-ID: <kz-OBtHpMvSJXEUamHFAKjVi77l9_tmZ7w0kWUwMguE=.e1dbb044-1f3d-4b04-83b7-1c77519c4308@github.com>

On Thu, 3 Dec 2020 15:16:47 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Compiler changes look good to me!
>
> Lois, Tobias,
> 
> thank you for your reviews.
> Lois' comments have been addressed in the latest commit.

Remi,

The current goal of the type restrictions branch is to measure the impact and the cost of type restrictions checks, so features are being added incrementally (not a full model yet). The current goal is not to provide a support for full reification, and some models being proposed on top of type restrictions are relying on the fact that type restrictions can only be applied to primitive classes.

For the first phase of this exploration, we should stick to the simple model until we reach the first mile-stone: full support of RestrictedField and RestrictedMethod in the interpreter, C1 and C2.

By the time we implement this first step, we hope we'll have a better understanding on how to evolve the model, relaxing constraints, keeping them or modifying them.

Regards,

Fred

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

PR: https://git.openjdk.java.net/valhalla/pull/288

From fparain at openjdk.java.net  Thu Dec  3 15:33:09 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Thu, 3 Dec 2020 15:33:09 GMT
Subject: Integrated: 8257600: [type-restrictions] Implement RestrictedField in
 C1
In-Reply-To: <Vtog3nPM_d5mWmjAfbrQs6d89K_AkhCVI0THwED9lbA=.e2c32fe7-b488-4114-8ccc-1f4712561c42@github.com>
References: <Vtog3nPM_d5mWmjAfbrQs6d89K_AkhCVI0THwED9lbA=.e2c32fe7-b488-4114-8ccc-1f4712561c42@github.com>
Message-ID: <DmKSWkVlEHdYk8ganUhfK-NeKl0NqEBdLdzFtcpDNfY=.bbfa8a9b-f2a5-43a5-90f1-68a08011b3fb@github.com>

On Wed, 2 Dec 2020 14:15:09 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review theses changes adding RestrictedField support to C1.
> Tests have been added using the annotation added by JDK-8255856.
> Tests revealed some issues with the support of RestrictedField in the interpreter, fixes are included in this patch.
> The changes also includes some renaming after discussions with Dan.
> 
> Thank you,
> 
> Fred

This pull request has now been integrated.

Changeset: ab439dca
Author:    Frederic Parain <fparain at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/ab439dca
Stats:     487 lines in 16 files changed: 454 ins; 5 del; 28 mod

8257600: [type-restrictions] Implement RestrictedField in C1

Reviewed-by: lfoltan, thartmann

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

PR: https://git.openjdk.java.net/valhalla/pull/288

From github.com+828220+forax at openjdk.java.net  Thu Dec  3 15:50:11 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 3 Dec 2020 15:50:11 GMT
Subject: RFR: 8257600: [type-restrictions] Implement RestrictedField in C1
 [v2]
In-Reply-To: <kz-OBtHpMvSJXEUamHFAKjVi77l9_tmZ7w0kWUwMguE=.e1dbb044-1f3d-4b04-83b7-1c77519c4308@github.com>
References: <Vtog3nPM_d5mWmjAfbrQs6d89K_AkhCVI0THwED9lbA=.e2c32fe7-b488-4114-8ccc-1f4712561c42@github.com>
 <QDWqiIaQ3Mw6cBFACW2zS5tTdvnWhgQpzU0MWKAW84k=.7a2d3ffa-ccb5-4ee8-a494-ceed5e1f01bd@github.com>
 <C1ZMDpKe3JhTdBYMd1a4vbtdAQ5LIqKG1I_SO3oTkm0=.eff37c15-6858-45b9-91ba-9c6976ce385c@github.com>
 <kz-OBtHpMvSJXEUamHFAKjVi77l9_tmZ7w0kWUwMguE=.e1dbb044-1f3d-4b04-83b7-1c77519c4308@github.com>
Message-ID: <fy1Xxc04_wdWfm1MSU3V7KnjC4l-j9aNtbpi8lBfYak=.d85659b6-3ebc-417e-9734-fb08315feb01@github.com>

On Thu, 3 Dec 2020 15:28:21 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> Lois, Tobias,
>> 
>> thank you for your reviews.
>> Lois' comments have been addressed in the latest commit.
>
> Remi,
> 
> The current goal of the type restrictions branch is to measure the impact and the cost of type restrictions checks, so features are being added incrementally (not a full model yet). The current goal is not to provide a support for full reification, and some models being proposed on top of type restrictions are relying on the fact that type restrictions can only be applied to primitive classes.
> 
> For the first phase of this exploration, we should stick to the simple model until we reach the first mile-stone: full support of RestrictedField and RestrictedMethod in the interpreter, C1 and C2.
> 
> By the time we implement this first step, we hope we'll have a better understanding on how to evolve the model, relaxing constraints, keeping them or modifying them.
> 
> Regards,
> 
> Fred

Hi Fr?d?ric,
nevermind, in the meantime, i can patch the attribute name so if it's not a record the attribute itself will not be recognized

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

PR: https://git.openjdk.java.net/valhalla/pull/288

From brian.goetz at oracle.com  Thu Dec  3 17:06:47 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 3 Dec 2020 12:06:47 -0500
Subject: Embrace nulls, was Re: Typed variants of primitives
In-Reply-To: <CACzrW9DGDm2k68Q7Bo6puRgbxqsfrTN0Detk0GDbafpjhCnsng@mail.gmail.com>
References: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>
 <F0FDCFB9-D95D-41EA-A0B6-7DAB199FA1A5@oracle.com>
 <CACzrW9CxEJRX6Bka6Lu8an8=gnWPb9rVhZp97KLk46JMaMG4TQ@mail.gmail.com>
 <f899ce6a-78c0-c2fc-4e61-838e8ec94a9d@oracle.com>
 <CACzrW9DGDm2k68Q7Bo6puRgbxqsfrTN0Detk0GDbafpjhCnsng@mail.gmail.com>
Message-ID: <2906ec2b-9d54-f725-84e4-b5a1f590dd8f@oracle.com>

All good thoughts.? Comments inline.

> Anyway, I've been meaning to throw an observation about nulls out for
> a few weeks: In recent language/library changes there has been a
> pushback to block or restrict null (streams, switch, patterns, etc),
> which eventually was rejected with a mantra of "embrace nulls"
> instead. Perhaps that same mantra of embracing nulls needs to be
> adopted by valhalla?

I see what you mean, but let me put some more nuance on the recent 
flurry of "embrace your inner null!" in other contexts.? This is not so 
much about loving nulls so much that we want all things to be nullable, 
as much as not trying to make nullable things into something they are 
not.? The domain of reference types includes null; things that work on 
references (e.g., Stream<T>, pattern matching on reference types) should 
not make unnecessary assumptions about the domain, lest we create sharp 
edges that inhibit otherwise sensible program transformations.

So this is not so much "everything should be nullable", as much as "of 
the things that are nullable, let them be what they are."? It's a 
message of tolerance :)

Secondarily, let me share an observation that may be obvious in 
hindsight, but was not obvious (to me, at least) at the start of this 
exercise.? Which is: nullability is a property of _object references_, 
not the a type itself.? This was not obvious because Java hasn't 
previously ever given us a way to deal with objects (like String) 
directly; we deal with them only through references. But key to 
understanding Valhalla is that for a given class (say String), there is 
a universe of instances of String, but they are not the members of the 
value set of the type String!? The value set of the type String consists 
of _references to_ instances of String, plus the special reference null.

This may sound like language mumbo-jumbo, but it is key to understanding 
the difference between Point.ref and Point.val.? It is _not_ the case 
that the value set of Point.ref is the value set of Point.val, plus 
null; the two value sets are in fact disjoint!? The value set of 
Point.ref is:

 ??? { null } union { ref(x) : x in Point.val }

(Mathematically, this is called an _adjunction_, where there is an 
isomorphism between a set X and a subset of some other set Y; the 
isomorphism takes care of the "reference to" part.)

And, this is a story that has been baked into the JVM from day one: JVMS 
2.2 ("Data types") says:

> There are, correspondingly, two
> kinds of values that can be stored in variables, passed as arguments, 
> returned by
> methods, and operated upon: primitive values and reference values


> By embracing nulls, I mean that valhalla could actively seek to ensure
> *every* value type has an associated first-class null form. Even those
> like int128. And without trying to hide the null under the carpet as
> the current reference type approach does (with the side effect of
> ruining the potential performance benefits by not flattening in many
> cases). Instead of null being an enemy to be dealt with, why not treat
> it as a welcome and useful friend?

"Why not" is a good question, but it has some good answers.? I think 
many people think the fact that `int` always refers to an actual 
integer, rather than possibly being null, is a feature, not a bug (at 
least for many uses of int.)?? I'm not sure that everyone would 
appreciate nulls being injected everywhere "for consistency."? And, as 
you observe, not all types have spare bit patterns, which means that 
there's a real cost to this nullity, which might not have been wanted in 
the first place.

> Group 1: Many potential value types have a spare bit pattern (eg.
> LocalDate). Asking them to arrange their bits so that all-zeroes is
> not used internally seems like an acceptable trade-off for the
> performance benefits. (I'm sure you've already explored mechanisms and
> syntaxes to do this). Group 1 would have just one exposed type, which
> would be nullable, avoiding the meaningless default problem (no
> LocalDate.val).

This is all true, though it's not only a matter of identifying the bit 
pattern corresponding to null; you also have to ensure that an NPE is 
thrown on the same kinds of access.

John made an impassioned plea for "No New Nulls", which is relevant; if 
we're going to have nullity, it should be a real null.
https://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2018-November/000784.html

> Group 2: For those value types that do not have a spare bit pattern,
> one would need to be added. This is the real "embrace nulls" moment,
> and I understand the pain of potentially forcing an Int128 class to
> take up 192 bits in memory. I do think it will rarely actually happen
> in practice though (see group 3). Group 2 is really just the same as
> group 1 but with wasteful memory usage, with one exposed nullable
> type.

For these especially, we have to be clear on why we would be embracing 
nulls, since the cost is felt so strongly here.

But another reason why "nullify all the things" is a questionable 
approach is: int and long will never be able to play.? So we will 
forever be left with a rift in the type system we cannot heal.? We can 
of course make all value types nullable, but it starts to undermine some 
of the reasons (among them, density) to have them in the first place.

> I also think this reduces the schism between valhalla types and
> reference-like. All new and migrated value types (eg Int128, Optional,
> LocalDate) would be UpperCamelCase and nullable, just like reference
> types.

I think you're falling into the same trap we fell into earlier, which is 
that the value set of a "primitive" type and the value set of a 
reference type are _different kinds of things_.? Essentially, by 
introducing null, you've made them all reference types.? That's not 
necessarily terrible, but it does add a constraint to types that may not 
want it.? As you point out, we can then try to optimize around it, but 
that means we can provide fewer guarantees.? Which brings me back to: 
what's the motivation?

Under the current approach, the default is that values are, well, 
values, but if you want nullability, you lift them into the domains 
where nulls already live -- reference types.? Point.ref is a reference 
type, so it is automatically nullable; Point.val consists of instances, 
not references, and null is not an instance.? So if you want 
nullability, you ask for it by saying what you really want: references.

This means that we can actually integrate primitives in a much more 
disciplined way.? In fact, while the original motivation of Valhalla was 
largely performance-driven -- flatness and density -- for many, the real 
benefit will be the unification of the type system, where we provide a 
rational basis for bridging primitives and classes, and the existing 
primitives are just "built-in" inline classes.


From john.r.rose at oracle.com  Thu Dec  3 18:51:39 2020
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 3 Dec 2020 10:51:39 -0800
Subject: Embrace nulls, was Re: Typed variants of primitives
In-Reply-To: <2906ec2b-9d54-f725-84e4-b5a1f590dd8f@oracle.com>
References: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>
 <F0FDCFB9-D95D-41EA-A0B6-7DAB199FA1A5@oracle.com>
 <CACzrW9CxEJRX6Bka6Lu8an8=gnWPb9rVhZp97KLk46JMaMG4TQ@mail.gmail.com>
 <f899ce6a-78c0-c2fc-4e61-838e8ec94a9d@oracle.com>
 <CACzrW9DGDm2k68Q7Bo6puRgbxqsfrTN0Detk0GDbafpjhCnsng@mail.gmail.com>
 <2906ec2b-9d54-f725-84e4-b5a1f590dd8f@oracle.com>
Message-ID: <6AC898E1-4A4A-4456-851E-EDA85254C948@oracle.com>

On Dec 3, 2020, at 9:06 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> It's a message of tolerance

As subtly opposed to, ?Whatever is not forbidden is compulsory.?

When I read your post, Stephen, I thought of the sort of fallacy
in ?That after dinner whiskey was so nice, I?ll have one for
breakfast every morning.?

? John

From scolebourne at joda.org  Fri Dec  4 00:04:04 2020
From: scolebourne at joda.org (Stephen Colebourne)
Date: Fri, 4 Dec 2020 00:04:04 +0000
Subject: Embrace nulls, was Re: Typed variants of primitives
In-Reply-To: <2906ec2b-9d54-f725-84e4-b5a1f590dd8f@oracle.com>
References: <CACzrW9CFJtMO9aaJk86hU1is4P-E_DtP39v4g9kG8UZsx4KQpA@mail.gmail.com>
 <F0FDCFB9-D95D-41EA-A0B6-7DAB199FA1A5@oracle.com>
 <CACzrW9CxEJRX6Bka6Lu8an8=gnWPb9rVhZp97KLk46JMaMG4TQ@mail.gmail.com>
 <f899ce6a-78c0-c2fc-4e61-838e8ec94a9d@oracle.com>
 <CACzrW9DGDm2k68Q7Bo6puRgbxqsfrTN0Detk0GDbafpjhCnsng@mail.gmail.com>
 <2906ec2b-9d54-f725-84e4-b5a1f590dd8f@oracle.com>
Message-ID: <CACzrW9D+iF8_1Z0rzpQqRWpRGQmRJYDA4VOpR=Fe6nZ9nYSq3w@mail.gmail.com>

On Thu, 3 Dec 2020 at 17:07, Brian Goetz <brian.goetz at oracle.com> wrote:
> Secondarily, let me share an observation that may be obvious in
> hindsight, but was not obvious (to me, at least) at the start of this
> exercise.  Which is: nullability is a property of _object references_,
> not the a type itself.  This was not obvious because Java hasn't
> previously ever given us a way to deal with objects (like String)
> directly; we deal with them only through references. But key to
> understanding Valhalla is that for a given class (say String), there is
> a universe of instances of String, but they are not the members of the
> value set of the type String!  The value set of the type String consists
> of _references to_ instances of String, plus the special reference null.

Yes, an object reference really is just another value, not much
different to an `int`. This issue is that the language hides this from
us instead of making it visible via a type `ref<T>`:

 public class Name {
   private final ref<String> forename;
   private final ref<String> surname;
   private final int age;
}

The only special thing with an object reference (`ref<T>`) is that the
content bits of a reference value is a pointer to an instance that the
JVM understands, a pointer that can only be accessed via a reference
value, and cannot be directly observed except in that way. And as you
say, the thing at the end of the pointer can't be null.

Since an object reference is actually a value, that means Java
*already has* values that can be null!!! Despite this fact, there is a
mythology that nulls are somehow special and must only be associated
with reference values. But apart from history and JVM sunk cost I
don't think there is any conceptual reason why that has to be so,
especially when user-defined values could make great use of treating
an all-zero bit pattern as a "null".

> Essentially, by introducing null, you've made them all reference types.

Ultimately "null" is just a name we give to a particular action taken
when the JVM finds the all-zero bit pattern. Sometimes we call the
all-zero bit pattern "null" with an action that throws NPE and
sometimes we call it "zero" or "false" with actions that can use it
fully. There really isn't any conceptual need to say that reference
values are the only ones allowed to use the name and action associated
with  "null", it is just history that we do.

(I do suspect it would require introducing something approaching an
actual `ref<T>` type in the JVM to which the throw NPE behaviour could
be attached. Also exposing it as a real type in the Java language
would provide syntax for sparse arrays of values for example).

> But another reason why "nullify all the things" is a questionable approach is: int and long will never be able to play.

We already have nullable int - Integer. What I'm suggesting doesn't
change that. Users would always code the nullable value type
(potentially with wasteful memory usage) but can still choose to write
the non-nullable one as well (satisfying your use cases and unifying
int). The change from the current valhalla approach is that Integer
would be a flattenable value type with a different size in memory to
int, not at the other end of a reference pointer. Bigger migration
problem for Integer/LocalDate of course.

> what's the motivation?

- I disagree with John that nullability and no good default are rare.
- I believe many if not most end-user classes have the potential to be
value types, not just a few special numeric classes in libraries.
- I don't believe an outcome where a memory hop is required to access
non-numeric values is acceptable
- I don't think developers benefit from having two exposed types for
values in most cases (this is only useful for numeric values where
zero has meaning)
- Controlling what fields/variables are or are not null is an
orthogonal problem, not something to be mixed into valhalla
- It is not because I like nulls, but because I believe they are the
best available option for uninitialized memory for non-numeric values

Anyway, I'll stop here - I'm well aware that this approach requires a
big leap relative to where valhalla currently is.
thanks
Stephen

From roland at openjdk.java.net  Fri Dec  4 16:59:31 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 4 Dec 2020 16:59:31 GMT
Subject: [lworld] RFR: 8257773: [lworld] fix compiler replay for new profile
 data
Message-ID: <5mxwZcverPBXj_Fz9DcePxWp0k8-i_9u6opJ0M0VPQs=.1d6051e4-5428-4384-adb0-bbd38c5ecb43@github.com>

Logic is missing to handle new profile data for array loads/stores and
acmp when a replay file is dump.

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

Commit messages:
 - fix

Changes: https://git.openjdk.java.net/valhalla/pull/293/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=293&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257773
  Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/293/head:pull/293

PR: https://git.openjdk.java.net/valhalla/pull/293

From dlsmith at openjdk.java.net  Fri Dec  4 20:44:30 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Fri, 4 Dec 2020 20:44:30 GMT
Subject: RFR: 8257776: [valhalla:jep390] Add disclaimer about future changes
 to value-based classes
Message-ID: <ZntaDnuG-Dkrof4DkLOFTEWrLVDEoTnhxGZ3HDBXRQs=.424d9f31-c311-41bd-ad87-d9827e2bfb5c@github.com>

Addressing CSR feedback by mentioning the possibility of future behavioral changes to value-based classes.

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

Commit messages:
 - 8257776: [valhalla:jep390] Add disclaimer about future changes to value-based classes

Changes: https://git.openjdk.java.net/valhalla/pull/294/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=294&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257776
  Stats: 81 lines in 45 files changed: 32 ins; 0 del; 49 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/294.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/294/head:pull/294

PR: https://git.openjdk.java.net/valhalla/pull/294

From dlsmith at openjdk.java.net  Fri Dec  4 21:45:36 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Fri, 4 Dec 2020 21:45:36 GMT
Subject: RFR: 8257776: [valhalla:jep390] Add disclaimer about future
 changes to value-based classes [v2]
In-Reply-To: <ZntaDnuG-Dkrof4DkLOFTEWrLVDEoTnhxGZ3HDBXRQs=.424d9f31-c311-41bd-ad87-d9827e2bfb5c@github.com>
References: <ZntaDnuG-Dkrof4DkLOFTEWrLVDEoTnhxGZ3HDBXRQs=.424d9f31-c311-41bd-ad87-d9827e2bfb5c@github.com>
Message-ID: <7-Wa5tzcigze0_RijAFPOs8M3YiwhLXnt-d3Uzgn5Mg=.59a31055-0fe1-42d4-a711-6372c6732685@github.com>

> Addressing CSR feedback by mentioning the possibility of future behavioral changes to value-based classes.

Dan Smith has updated the pull request incrementally with one additional commit since the last revision:

  Rephrase "future release" warning.

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/294/files
  - new: https://git.openjdk.java.net/valhalla/pull/294/files/e0270e7e..bacb42ee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=294&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=294&range=00-01

  Stats: 50 lines in 44 files changed: 0 ins; 0 del; 50 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/294.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/294/head:pull/294

PR: https://git.openjdk.java.net/valhalla/pull/294

From mchung at openjdk.java.net  Fri Dec  4 21:54:24 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 4 Dec 2020 21:54:24 GMT
Subject: RFR: 8257776: [valhalla:jep390] Add disclaimer about future
 changes to value-based classes [v2]
In-Reply-To: <7-Wa5tzcigze0_RijAFPOs8M3YiwhLXnt-d3Uzgn5Mg=.59a31055-0fe1-42d4-a711-6372c6732685@github.com>
References: <ZntaDnuG-Dkrof4DkLOFTEWrLVDEoTnhxGZ3HDBXRQs=.424d9f31-c311-41bd-ad87-d9827e2bfb5c@github.com>
 <7-Wa5tzcigze0_RijAFPOs8M3YiwhLXnt-d3Uzgn5Mg=.59a31055-0fe1-42d4-a711-6372c6732685@github.com>
Message-ID: <iUhWY9OV4CLfpHTG6ceXcE6gbUuV0Agnaax1gc93Fdo=.92f40a3c-ed10-4aea-9bfc-a59de8fafa1c@github.com>

On Fri, 4 Dec 2020 21:45:36 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>> Addressing CSR feedback by mentioning the possibility of future behavioral changes to value-based classes.
>
> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rephrase "future release" warning.

Marked as reviewed by mchung (Reviewer).

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 44:

> 42:  * All implementations of this interface must be <a href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a>;
> 43:  * programmers should treat instances that are {@linkplain #equals(Object) equal} as interchangeable and should not
> 44:  * use instances for synchronization, or unpredictable behavior may occur. For example, in a future release, synchronization may fail.

Nit: this line is very long and maybe good to wrap this line and the line above..   I understand that the javadoc in this file has long lines and href is an outliner.

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

PR: https://git.openjdk.java.net/valhalla/pull/294

From rriggs at openjdk.java.net  Fri Dec  4 21:54:25 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 4 Dec 2020 21:54:25 GMT
Subject: RFR: 8257776: [valhalla:jep390] Add disclaimer about future
 changes to value-based classes [v2]
In-Reply-To: <7-Wa5tzcigze0_RijAFPOs8M3YiwhLXnt-d3Uzgn5Mg=.59a31055-0fe1-42d4-a711-6372c6732685@github.com>
References: <ZntaDnuG-Dkrof4DkLOFTEWrLVDEoTnhxGZ3HDBXRQs=.424d9f31-c311-41bd-ad87-d9827e2bfb5c@github.com>
 <7-Wa5tzcigze0_RijAFPOs8M3YiwhLXnt-d3Uzgn5Mg=.59a31055-0fe1-42d4-a711-6372c6732685@github.com>
Message-ID: <4-LsE4o1BDNg9wbRruanzOFcbwv2Y-EHuIW5IcP8hQ0=.2d253a7f-67c6-4ba2-b6b7-b35ebaba7bf6@github.com>

On Fri, 4 Dec 2020 21:45:36 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>> Addressing CSR feedback by mentioning the possibility of future behavioral changes to value-based classes.
>
> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rephrase "future release" warning.

Marked as reviewed by rriggs (Reviewer).

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 44:

> 42:  * All implementations of this interface must be <a href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a>;
> 43:  * programmers should treat instances that are {@linkplain #equals(Object) equal} as interchangeable and should not
> 44:  * use instances for synchronization, or unpredictable behavior may occur. For example, in a future release, synchronization may fail.

Add a line break before the new sentence and in MemoryLayout.java and MemorySegment.java

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

PR: https://git.openjdk.java.net/valhalla/pull/294

From dlsmith at openjdk.java.net  Fri Dec  4 22:06:37 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Fri, 4 Dec 2020 22:06:37 GMT
Subject: RFR: 8257776: [valhalla:jep390] Add disclaimer about future
 changes to value-based classes [v3]
In-Reply-To: <ZntaDnuG-Dkrof4DkLOFTEWrLVDEoTnhxGZ3HDBXRQs=.424d9f31-c311-41bd-ad87-d9827e2bfb5c@github.com>
References: <ZntaDnuG-Dkrof4DkLOFTEWrLVDEoTnhxGZ3HDBXRQs=.424d9f31-c311-41bd-ad87-d9827e2bfb5c@github.com>
Message-ID: <Ho6KpLUc677r9dBDwHZd3rsiv31ZN43pZpO1dJKyy_I=.6dad5c7c-8d80-4828-950f-9af97a9c1267@github.com>

> Addressing CSR feedback by mentioning the possibility of future behavioral changes to value-based classes.

Dan Smith has updated the pull request incrementally with one additional commit since the last revision:

  Add synchronization example to ValueBased.html

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/294/files
  - new: https://git.openjdk.java.net/valhalla/pull/294/files/bacb42ee..f35d5acf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=294&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=294&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/294.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/294/head:pull/294

PR: https://git.openjdk.java.net/valhalla/pull/294

From dlsmith at openjdk.java.net  Fri Dec  4 22:27:24 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Fri, 4 Dec 2020 22:27:24 GMT
Subject: RFR: 8257776: [valhalla:jep390] Add disclaimer about future
 changes to value-based classes [v2]
In-Reply-To: <iUhWY9OV4CLfpHTG6ceXcE6gbUuV0Agnaax1gc93Fdo=.92f40a3c-ed10-4aea-9bfc-a59de8fafa1c@github.com>
References: <ZntaDnuG-Dkrof4DkLOFTEWrLVDEoTnhxGZ3HDBXRQs=.424d9f31-c311-41bd-ad87-d9827e2bfb5c@github.com>
 <7-Wa5tzcigze0_RijAFPOs8M3YiwhLXnt-d3Uzgn5Mg=.59a31055-0fe1-42d4-a711-6372c6732685@github.com>
 <iUhWY9OV4CLfpHTG6ceXcE6gbUuV0Agnaax1gc93Fdo=.92f40a3c-ed10-4aea-9bfc-a59de8fafa1c@github.com>
Message-ID: <oqPqkrkm7awDi2XlrnEh0roVBTMD6xwY63Xb66vY2Qk=.475a2d4f-f208-42c0-b91c-0d23194bf657@github.com>

On Fri, 4 Dec 2020 21:49:07 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Dan Smith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rephrase "future release" warning.
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 44:
> 
>> 42:  * All implementations of this interface must be <a href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a>;
>> 43:  * programmers should treat instances that are {@linkplain #equals(Object) equal} as interchangeable and should not
>> 44:  * use instances for synchronization, or unpredictable behavior may occur. For example, in a future release, synchronization may fail.
> 
> Nit: this line is very long and maybe good to wrap this line and the line above..   I understand that the javadoc in this file has long lines and href is an outliner.

Yeah, it's not conventional, but it's the style in this file, so I decided not to perturb it. This is an incubator module, I assume it will get polished up before becoming final.

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

PR: https://git.openjdk.java.net/valhalla/pull/294

From dlsmith at openjdk.java.net  Fri Dec  4 22:33:38 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Fri, 4 Dec 2020 22:33:38 GMT
Subject: RFR: 8257776: [valhalla:jep390] Add disclaimer about future
 changes to value-based classes [v4]
In-Reply-To: <ZntaDnuG-Dkrof4DkLOFTEWrLVDEoTnhxGZ3HDBXRQs=.424d9f31-c311-41bd-ad87-d9827e2bfb5c@github.com>
References: <ZntaDnuG-Dkrof4DkLOFTEWrLVDEoTnhxGZ3HDBXRQs=.424d9f31-c311-41bd-ad87-d9827e2bfb5c@github.com>
Message-ID: <wFxk5x2HpfCpvWciU58xAC_CREUpOjWSYbvROq7i3XA=.92c13ad2-d4d6-4eb3-bed5-d23bf197bfe8@github.com>

> Addressing CSR feedback by mentioning the possibility of future behavioral changes to value-based classes.

Dan Smith has updated the pull request incrementally with one additional commit since the last revision:

  Wrap lines to <120 chars

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/294/files
  - new: https://git.openjdk.java.net/valhalla/pull/294/files/f35d5acf..a51ee1a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=294&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=294&range=02-03

  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/294.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/294/head:pull/294

PR: https://git.openjdk.java.net/valhalla/pull/294

From dlsmith at openjdk.java.net  Fri Dec  4 22:33:39 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Fri, 4 Dec 2020 22:33:39 GMT
Subject: RFR: 8257776: [valhalla:jep390] Add disclaimer about future
 changes to value-based classes [v2]
In-Reply-To: <oqPqkrkm7awDi2XlrnEh0roVBTMD6xwY63Xb66vY2Qk=.475a2d4f-f208-42c0-b91c-0d23194bf657@github.com>
References: <ZntaDnuG-Dkrof4DkLOFTEWrLVDEoTnhxGZ3HDBXRQs=.424d9f31-c311-41bd-ad87-d9827e2bfb5c@github.com>
 <7-Wa5tzcigze0_RijAFPOs8M3YiwhLXnt-d3Uzgn5Mg=.59a31055-0fe1-42d4-a711-6372c6732685@github.com>
 <iUhWY9OV4CLfpHTG6ceXcE6gbUuV0Agnaax1gc93Fdo=.92f40a3c-ed10-4aea-9bfc-a59de8fafa1c@github.com>
 <oqPqkrkm7awDi2XlrnEh0roVBTMD6xwY63Xb66vY2Qk=.475a2d4f-f208-42c0-b91c-0d23194bf657@github.com>
Message-ID: <bFCJYGtp0vL_jilORyI70RpiUZ7MvJAlu7UQZds6TSk=.63058b94-bd11-4e95-be81-812f0bc767fb@github.com>

On Fri, 4 Dec 2020 22:25:05 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 44:
>> 
>>> 42:  * All implementations of this interface must be <a href="{@docRoot}/java.base/java/lang/doc-files/ValueBased.html">value-based</a>;
>>> 43:  * programmers should treat instances that are {@linkplain #equals(Object) equal} as interchangeable and should not
>>> 44:  * use instances for synchronization, or unpredictable behavior may occur. For example, in a future release, synchronization may fail.
>> 
>> Nit: this line is very long and maybe good to wrap this line and the line above..   I understand that the javadoc in this file has long lines and href is an outliner.
>
> Yeah, it's not conventional, but it's the style in this file, so I decided not to perturb it. This is an incubator module, I assume it will get polished up before becoming final.

Ok, Roger said the same thing, I guess I tweak it.

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

PR: https://git.openjdk.java.net/valhalla/pull/294

From dlsmith at openjdk.java.net  Fri Dec  4 22:33:39 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Fri, 4 Dec 2020 22:33:39 GMT
Subject: Integrated: 8257776: [valhalla:jep390] Add disclaimer about future
 changes to value-based classes
In-Reply-To: <ZntaDnuG-Dkrof4DkLOFTEWrLVDEoTnhxGZ3HDBXRQs=.424d9f31-c311-41bd-ad87-d9827e2bfb5c@github.com>
References: <ZntaDnuG-Dkrof4DkLOFTEWrLVDEoTnhxGZ3HDBXRQs=.424d9f31-c311-41bd-ad87-d9827e2bfb5c@github.com>
Message-ID: <v0qgTLyltmzwqHKK_Gupa34iZRS3QBInqrPhg881bAI=.ee1c403d-3b1c-4e3b-8635-f874fe8a8d2c@github.com>

On Fri, 4 Dec 2020 20:39:47 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Addressing CSR feedback by mentioning the possibility of future behavioral changes to value-based classes.

This pull request has now been integrated.

Changeset: 54ba37be
Author:    Dan Smith <dlsmith at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/54ba37be
Stats:     81 lines in 45 files changed: 33 ins; 0 del; 48 mod

8257776: [valhalla:jep390] Add disclaimer about future changes to value-based classes

Reviewed-by: mchung, rriggs

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

PR: https://git.openjdk.java.net/valhalla/pull/294

From paul.sandoz at oracle.com  Sat Dec  5 01:11:29 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 4 Dec 2020 17:11:29 -0800
Subject: Issue with separate compilation and a generic inline type
Message-ID: <1B949771-9070-4E8F-B28E-5D5B59A4EF8F@oracle.com>

Hi,

If I have this inline class and a test class

public inline class Range<T> {
    private final T lower;
    private final T upper;

    private Range(T lower, T upper) {
        this.lower = lower;
        this.upper = upper;
    }

    public static <T> Range<T> of(T lower, T upper) {
        return new Range<>(lower, upper);
    }
}

public class Test {
    public static void main(String[] args) {
        Range<Integer> r = Range.of(1, 2);
    }
}

Compiling Range first and then, separately, Test fails:


$ javac Range.java
$ javac Test.java
Test.java:3: error: cannot access Range
        Range<Integer> r = Range.of(1, 2);
        ^
  bad class file: ./Range.class
    method descriptor invalid for <init>
    Please remove or make sure it appears in the correct subdirectory of the classpath.
1 error

This came about as I was writing some inline classes and corresponding tests.

So I started poking around the class file and javac code.

A constructor for an inline class declares that class as the return type of method-related constants/attributes:

#10 = Methodref          #1.#11         // Range."<init>":(Ljava/lang/Object;Ljava/lang/Object;)QRange;
#11 = NameAndType        #12:#13        // "<init>":(Ljava/lang/Object;Ljava/lang/Object;)QRange;
#12 = Utf8               <init>
...
private static Range<T> Range(java.lang.Object, java.lang.Object);
  descriptor: (Ljava/lang/Object;Ljava/lang/Object;)QRange;
...
  Signature: #22                          // (Ljava/lang/Object;Ljava/lang/Object;)QRange<TT;>;

For reference classes the return type is void (V).


In javac, ClassReader.readMethod first creates a MethodType instance for ?<init>? with an explicit void return type, which gets applied to the MethodSymbol instance. Signature attribute parsing then updates the MethodSymbol?s type with the result of parsing the constructor signature attribute, thus a non-void return type appears, which then fails the method validation check.


I bodged javac with this patch:

--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
@@ -2254,7 +2254,7 @@ public class ClassReader {
         if (name == names.init && ((flags & STATIC) != 0)) {
             flags &= ~STATIC;
             type = new MethodType(type.getParameterTypes(),
-                    syms.voidType,
+                    currentOwner.isValue() ? currentOwner.type : syms.voidType,
                     type.getThrownTypes(),
                     syms.methodClass);
         }
@@ -2302,7 +2302,7 @@ public class ClassReader {
 
     void validateMethodType(Name name, Type t) {
         if ((!t.hasTag(TypeTag.METHOD) && !t.hasTag(TypeTag.FORALL)) ||
-            (name == names.init && !t.getReturnType().hasTag(TypeTag.VOID))) {
+            (name == names.init && !currentOwner.isValue() && !t.getReturnType().hasTag(TypeTag.VOID))) {
             throw badClassFile("method.descriptor.invalid", name);
         }
     }

? but I don?t really know what the implications are.

Paul.

From christian.beikov at gmail.com  Sat Dec  5 01:35:23 2020
From: christian.beikov at gmail.com (Christian Beikov)
Date: Sat, 5 Dec 2020 02:35:23 +0100
Subject: Null support for inline class reference projections through bitmaps
Message-ID: <8a331ca4-b86c-59d9-7e90-7984cdce5663@gmail.com>

Hi,

up until now I was mainly reading mailing list topics and watching 
Youtube videos about Valhalla, but since default values for inline 
classes were recently discussed again in the "Embrace nulls" topic I 
wanted to discuss/share an idea I had.

Since there are types like e.g. LocalDate which would like to be inline 
classes but don't have a good default value, I was thinking about how 
the default value for value projections could be avoided and null could 
be used as default for reference projections efficiently.

1. How to avoid the need for default values for value projections

As far as I understood, default values are only relevant in the 
following contexts:

1.1. When accessing uninitialized fields of a value projection inline 
class type, one can observe the all zero bit value.

If we could disallow read access to such uninitialized fields and 
require explicit initialization through the verifier, the VM could 
safely continue using the all zero bit pattern for object allocation.

1.2. After value projection array creation, array elements are 
initialized with default values.

What if the creation of value projection arrays is only allowed for 
inline classes that have a default constructor(in the newarray bytecode 
the VM initializes the cached default value as created by the default 
constructor) and through an intrinsic method e.g. <any T> T.val[] 
Arrays.unbox(T.ref[]) that does null checks?


Am I missing something or would these restrictions make default values 
for inline classes optional? Could the fact that a default constructor 
exists be used to model whether the inline class name should refer to 
the value or reference projection by default?


2. Support nulls for reference projection (efficiently?)

Maybe you already work on something like that, but so far, I was of the 
impression that reference projections for inline classes wouldn't be 
that much better than normal reference types, so I thought about how 
reference projections could be modeled efficiently.

The general idea I have is to introduce a bitmap to track the nullness 
of all (transitive) reference projections within a container like an 
array or object.

Here a quick example to showcase what I mean:

record NormalClass(Value1.val v1, Value2.ref v2){}
inline record Value1(long l){}
inline record Value2(Value.ref v1, long l2){}

The transitive reference projections in NormalClass are v2 and v2.v1. 
Similarly, for Value2.ref[] nullness must be tracked for the element 
itself and element.v1.

For types with a size + bitmap size <= word size, the bitmap could be 
made a part of the word for the value. Bitmaps for bigger types would be 
merged together in a container. A merged bitmap would track nullness for 
reference projections within a cache line boundary such that every cache 
line has a merged bitmap for the elements on the cache line.

This bitmap approach should be applicable in all cases, for local 
variables, fields and arrays.


Is this bitmap approach for nullness tracking of reference projections 
something you are already doing? If not, why and what other approach are 
you using then?


Regards,

Christian


From dlsmith at openjdk.java.net  Sat Dec  5 01:40:38 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Sat, 5 Dec 2020 01:40:38 GMT
Subject: Integrated: Merge valhalla:master
Message-ID: <UOuKiauiupu0VfnvaSfeutKjQxCmj-FeRqLWDVhMxAY=.5900656b-e805-471b-9c1d-bc96d245a435@github.com>

Merge from tag jdk-16+27

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

Commit messages:
 - Merge tag 'jdk-16+27' into jep390-merge/jdk-16+27
 - 8256818: SSLSocket that is never bound or connected leaks socket resources
 - 8257189: Handle concurrent updates of MH.form better
 - 8257565: epsilonBarrierSet.hpp should not include barrierSetAssembler
 - 8256256: UL should not use heap allocation for output string
 - 8257140: Crash in JvmtiTagMap::flush_object_free_events()
 - 8253916: ResourceExhausted/resexhausted001 crashes on Linux-x64
 - 8254877: GCLogPrecious::_lock rank constrains what locks you are allowed to have when crashing
 - 8256382: Use try_lock for hs_err EventLog printing
 - 8257533: legacy-jre-image includes jpackage and jlink tools
 - ... and 252 more: https://git.openjdk.java.net/valhalla/compare/54ba37be...de7f27b0

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - jep390: https://webrevs.openjdk.java.net/?repo=valhalla&pr=295&range=00.0
 - valhalla:master: https://webrevs.openjdk.java.net/?repo=valhalla&pr=295&range=00.1

Changes: https://git.openjdk.java.net/valhalla/pull/295/files
  Stats: 209295 lines in 1490 files changed: 136159 ins; 52121 del; 21015 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/295.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/295/head:pull/295

PR: https://git.openjdk.java.net/valhalla/pull/295

From dlsmith at openjdk.java.net  Sat Dec  5 01:40:42 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Sat, 5 Dec 2020 01:40:42 GMT
Subject: Integrated: Merge valhalla:master
In-Reply-To: <UOuKiauiupu0VfnvaSfeutKjQxCmj-FeRqLWDVhMxAY=.5900656b-e805-471b-9c1d-bc96d245a435@github.com>
References: <UOuKiauiupu0VfnvaSfeutKjQxCmj-FeRqLWDVhMxAY=.5900656b-e805-471b-9c1d-bc96d245a435@github.com>
Message-ID: <5iDGWriDlIfq0qsM9fkpHILoBTd5NVqmskk3oeeJXrg=.97a540df-cee6-40a1-9346-06ea3de0fc1f@github.com>

On Sat, 5 Dec 2020 01:29:49 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Merge from tag jdk-16+27

This pull request has now been integrated.

Changeset: 7c5e5bfe
Author:    Dan Smith <dlsmith at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/7c5e5bfe
Stats:     209295 lines in 1490 files changed: 136159 ins; 52121 del; 21015 mod

Merge

Merge jdk tag 'jdk-16+27'

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

PR: https://git.openjdk.java.net/valhalla/pull/295

From christian.beikov at gmail.com  Sat Dec  5 11:12:27 2020
From: christian.beikov at gmail.com (Christian Beikov)
Date: Sat, 5 Dec 2020 12:12:27 +0100
Subject: Null support for inline class reference projections through
 bitmaps
In-Reply-To: <8a331ca4-b86c-59d9-7e90-7984cdce5663@gmail.com>
References: <8a331ca4-b86c-59d9-7e90-7984cdce5663@gmail.com>
Message-ID: <CANMUGsUNxTxhCx5dG+W_NX=xQ7NmB8XafKDnbXG1YEGijDMv4A@mail.gmail.com>

Forget section 1. I thought about this again after getting some sleep, and
I now realize that a default value for value projections is necessary for
e.g. collections to be usable with these types.

Have you decided yet if inline classes are allowed to specify custom
default values?

Regards,
Christian


Christian Beikov <christian.beikov at gmail.com> schrieb am Sa., 5. Dez. 2020,
02:35:

> Hi,
>
> up until now I was mainly reading mailing list topics and watching Youtube
> videos about Valhalla, but since default values for inline classes were
> recently discussed again in the "Embrace nulls" topic I wanted to
> discuss/share an idea I had.
>
> Since there are types like e.g. LocalDate which would like to be inline
> classes but don't have a good default value, I was thinking about how the
> default value for value projections could be avoided and null could be used
> as default for reference projections efficiently.
>
> 1. How to avoid the need for default values for value projections
>
> As far as I understood, default values are only relevant in the following
> contexts:
>
> 1.1. When accessing uninitialized fields of a value projection inline
> class type, one can observe the all zero bit value.
>
> If we could disallow read access to such uninitialized fields and require
> explicit initialization through the verifier, the VM could safely continue
> using the all zero bit pattern for object allocation.
>
> 1.2. After value projection array creation, array elements are initialized
> with default values.
>
> What if the creation of value projection arrays is only allowed for inline
> classes that have a default constructor(in the newarray bytecode the VM
> initializes the cached default value as created by the default constructor)
> and through an intrinsic method e.g. <any T> T.val[] Arrays.unbox(T.ref[])
> that does null checks?
>
>
> Am I missing something or would these restrictions make default values for
> inline classes optional? Could the fact that a default constructor exists
> be used to model whether the inline class name should refer to the value or
> reference projection by default?
>
> 2. Support nulls for reference projection (efficiently?)
>
> Maybe you already work on something like that, but so far, I was of the
> impression that reference projections for inline classes wouldn't be that
> much better than normal reference types, so I thought about how reference
> projections could be modeled efficiently.
>
> The general idea I have is to introduce a bitmap to track the nullness of
> all (transitive) reference projections within a container like an array or
> object.
>
> Here a quick example to showcase what I mean:
> record NormalClass(Value1.val v1, Value2.ref v2){}
> inline record Value1(long l){}
> inline record Value2(Value.ref v1, long l2){}
>
> The transitive reference projections in NormalClass are v2 and v2.v1.
> Similarly, for Value2.ref[] nullness must be tracked for the element
> itself and element.v1.
>
> For types with a size + bitmap size <= word size, the bitmap could be
> made a part of the word for the value. Bitmaps for bigger types would be
> merged together in a container. A merged bitmap would track nullness for
> reference projections within a cache line boundary such that every cache
> line has a merged bitmap for the elements on the cache line.
>
> This bitmap approach should be applicable in all cases, for local
> variables, fields and arrays.
>
>
> Is this bitmap approach for nullness tracking of reference projections
> something you are already doing? If not, why and what other approach are
> you using then?
>
>
> Regards,
>
> Christian
>

From brian.goetz at oracle.com  Sat Dec  5 13:44:31 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sat, 5 Dec 2020 08:44:31 -0500
Subject: Null support for inline class reference projections through
 bitmaps
In-Reply-To: <8a331ca4-b86c-59d9-7e90-7984cdce5663@gmail.com>
References: <8a331ca4-b86c-59d9-7e90-7984cdce5663@gmail.com>
Message-ID: <9690037F-399F-4F6F-A61A-19B9DCCFFE83@oracle.com>

> Since there are types like e.g. LocalDate which would like to be inline classes but don't have a good default value, I was thinking about how the default value for value projections could be avoided and null could be used as default for reference projections efficiently.

For a reference projection, null is a valid value, and is the default.  But, there?s no free lunch; if we have to represent them as references on the stack, then there?s going to be some cost (usually to the calling conventions.)  

The key thing to realize is that null is a property of reference-ness.  And while it is possible for the VM to still scalarize in this case (inflate an extra boolean channel for nullity), this is starting to approach heroics.  

> 1.2. After value projection array creation, array elements are initialized with default values.
> 
> What if the creation of value projection arrays is only allowed for inline classes that have a default constructor(in the newarray bytecode the VM initializes the cached default value as created by the default constructor) and through an intrinsic method e.g. <any T> T.val[] Arrays.unbox(T.ref[]) that does null checks?

The issue of whether there is _any_ good default, and whether all zero bits is a good default, are frequently conflated.  The ?no arg constructor? direction is only helpful in the case where there is a good default, but zeroes isn?t it.  But that?s the easier of the two problems to solve (though already not easy.)  

Consider a tuple of (String, String) which represents a name.  Is there any good default?  (null, null) is clearly crappy, but (??, ??) isn?t much better, nor is (?name unavailable?, ?name unavailable?).  So there?s no no-arg constructor that could help here.  But, do we want to say ?sorry, no flattened arrays of names??  

The approach of having separate types for the reference and value projections gives users a choice, where cost and safety can be balanced with an understanding of the context.  


> 2. Support nulls for reference projection (efficiently?)
> 
> Maybe you already work on something like that, but so far, I was of the impression that reference projections for inline classes wouldn't be that much better than normal reference types, so I thought about how reference projections could be modeled efficiently.

It?s in the middle.  Since there are pervasive implicit conversions between the two, and the JIT can more easily remove these conversions than it can with boxing, you can use Foo.val in the heap (arrays, fields) and Foo.ref in APIs.  This gets you flattening and density, but not the full benefit of scalarization in calls.  (As mentioned earlier, it might be possible to rescue scalarization in the presence of nulls, but that?s a long way off, if ever.)  

> The general idea I have is to introduce a bitmap to track the nullness of all (transitive) reference projections within a container like an array or object.

Essentially, if you want to adjoin an additional value to the value set of a type, you have several choices:

 - find an unused bit pattern (usually requires help from the programmer)
 - use more space, either contiguously (jam in an extra boolean field) or on the side (like your bitmap)

Languages that support an ?undefined? value (e.g., Perl) have the same problem.  

Stepping back, let?s remember how we got here: primitive classes (note the new name!) are intended to model _values_.  This kind of suggests that all their bits should be able to travel together.  

I think the reality is that if you want nullity in the sense of ?nothing there", then what you want is a reference type, because nulls only make sense when we?re talking about references to objects.  (And saying ?I want nullity, but I want a primitive class because it?s faster? is understandable, but mostly wishful thinking.)  

I think the more important question here is the other one, which is: what do we do about primitive classes that _are_ values, but which have no good default, such as Date.   Jan 1 1972 is not a good default; countless bugs have resulted from pretending it is.  (Using -1 to initiatialize dates just moves the problem to Dec 31.)  So there?s really no good default here, any more than (?not a name?, ?not a name?) is a good default for a Name tuple of (String, String).  So, what do we do?  

There?s a range of options here, trading off runtime cost, intrusiveness to the implementor, and intrusiveness to the client for cases where there is no good default.  

1.  Just use an identity class.  Null is the sensible default.  This isn?t a terrible choice.  Performance of Java today for business applications is pretty darn good. Easy for everyone, but we pay for it.  

2.  Use the val projection in implementation (fields, arrays) and ref projection in APIs.  This ensure safety at the boundary while offering the opportunity to get more flattening internally.  We get most of the performance benefits, relatively unintrusive, except someone has to stare at that ugly ?.ref? token.  

3.  Code your primitive class to (a) have no exposed fields and (b) for methods to be defensive about checking for zero on entry.  This gives the user everything they want ? fail-fast in the event they accidentially used an uninitialized value, and you get all the flatness, density, scalarlization, etc.  Higher intrusiveness to the implementor, no externally visible differences, full runtime cost savings.  



From srikanth.adayapalam at oracle.com  Mon Dec  7 07:27:39 2020
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Mon, 7 Dec 2020 12:57:39 +0530
Subject: inline record ref projection contains an empty record attribute
In-Reply-To: <1017263548.2005297.1606911486680.JavaMail.zimbra@u-pem.fr>
References: <1017263548.2005297.1606911486680.JavaMail.zimbra@u-pem.fr>
Message-ID: <dd2f7811-c238-eae9-1cf7-eb4b9afd79d0@oracle.com>

Hi Remi,

Thanks for the problem report. 
https://bugs.openjdk.java.net/browse/JDK-8251041 tracks the issues 
relating to inline records.
We know of quite a few issues. (including reported by you in the past) - 
Jim is looking into these.

Srikanth

On 02/12/20 5:48 pm, Remi Forax wrote:
> Hi all,
> using this inline record
>
> public @__inline__ record IntBox(int value) {}
>
> When the compiler generates the ref projection, IntBox$Ref, an empty attribute "Record" is generated which i believe is a mistake.
> The ref projection should not contains that attribute at all.
>
> regards,
> R?mi
>
> ---
> Classfile /home/forax/git/transmogrif/target/classes/fr/umlv/transmogrif/IntBox$ref.class
>    Last modified Dec 2, 2020; size 222 bytes
>    SHA-256 checksum 2ee826fe2e8735044ea2a7f9e766aa101a7786385b5d27291864e7e4d550d6e2
>    Compiled from "IntBox.java"
> public abstract class fr.umlv.transmogrif.IntBox$ref extends java.lang.Record
>    minor version: 0
>    major version: 60
>    flags: (0x0421) ACC_PUBLIC, ACC_SUPER, ACC_ABSTRACT
>    this_class: #1                          // fr/umlv/transmogrif/IntBox$ref
>    super_class: #3                         // java/lang/Record
>    interfaces: 0, fields: 0, methods: 0, attributes: 4
> Constant pool:
>     #1 = Class              #2             // fr/umlv/transmogrif/IntBox$ref
>     #2 = Utf8               fr/umlv/transmogrif/IntBox$ref
>     #3 = Class              #4             // java/lang/Record
>     #4 = Utf8               java/lang/Record
>     #5 = Utf8               SourceFile
>     #6 = Utf8               IntBox.java
>     #7 = Utf8               NestMembers
>     #8 = Class              #9             // fr/umlv/transmogrif/IntBox
>     #9 = Utf8               fr/umlv/transmogrif/IntBox
>    #10 = Utf8               Record                                     <------------ oops
>    #11 = Utf8               PermittedSubclasses
> {
> }
> SourceFile: "IntBox.java"
> NestMembers:
>    fr/umlv/transmogrif/IntBox
> PermittedSubclasses:
>    fr/umlv/transmogrif/IntBox
> Record:
> [forax at localhost transmogrif]$ javap -private -c -verbose target/classes/fr/umlv/transmogrif/IntBox\$ref.class
> Classfile /home/forax/git/transmogrif/target/classes/fr/umlv/transmogrif/IntBox$ref.class
>    Last modified Dec 2, 2020; size 222 bytes
>    SHA-256 checksum 2ee826fe2e8735044ea2a7f9e766aa101a7786385b5d27291864e7e4d550d6e2
>    Compiled from "IntBox.java"
> public abstract class fr.umlv.transmogrif.IntBox$ref extends java.lang.Record
>    minor version: 0
>    major version: 60
>    flags: (0x0421) ACC_PUBLIC, ACC_SUPER, ACC_ABSTRACT
>    this_class: #1                          // fr/umlv/transmogrif/IntBox$ref
>    super_class: #3                         // java/lang/Record
>    interfaces: 0, fields: 0, methods: 0, attributes: 4
> Constant pool:
>     #1 = Class              #2             // fr/umlv/transmogrif/IntBox$ref
>     #2 = Utf8               fr/umlv/transmogrif/IntBox$ref
>     #3 = Class              #4             // java/lang/Record
>     #4 = Utf8               java/lang/Record
>     #5 = Utf8               SourceFile
>     #6 = Utf8               IntBox.java
>     #7 = Utf8               NestMembers
>     #8 = Class              #9             // fr/umlv/transmogrif/IntBox
>     #9 = Utf8               fr/umlv/transmogrif/IntBox
>    #10 = Utf8               Record
>    #11 = Utf8               PermittedSubclasses
> {
> }
> SourceFile: "IntBox.java"
> NestMembers:
>    fr/umlv/transmogrif/IntBox
> PermittedSubclasses:
>    fr/umlv/transmogrif/IntBox
> Record:                                 <------------------------ oops
>


From srikanth.adayapalam at oracle.com  Mon Dec  7 07:37:27 2020
From: srikanth.adayapalam at oracle.com (Srikanth)
Date: Mon, 7 Dec 2020 13:07:27 +0530
Subject: Issue with separate compilation and a generic inline type
In-Reply-To: <1B949771-9070-4E8F-B28E-5D5B59A4EF8F@oracle.com>
References: <1B949771-9070-4E8F-B28E-5D5B59A4EF8F@oracle.com>
Message-ID: <6603656c-3c21-db65-97ad-df7d6dc4002e@oracle.com>

Hi Paul,

May I request you to raise a JBS ticket ? I will follow up - TIA.

Srikanth

On 05/12/20 6:41 am, Paul Sandoz wrote:
> Hi,
>
> If I have this inline class and a test class
>
> public inline class Range<T> {
>      private final T lower;
>      private final T upper;
>
>      private Range(T lower, T upper) {
>          this.lower = lower;
>          this.upper = upper;
>      }
>
>      public static <T> Range<T> of(T lower, T upper) {
>          return new Range<>(lower, upper);
>      }
> }
>
> public class Test {
>      public static void main(String[] args) {
>          Range<Integer> r = Range.of(1, 2);
>      }
> }
>
> Compiling Range first and then, separately, Test fails:
>
>
> $ javac Range.java
> $ javac Test.java
> Test.java:3: error: cannot access Range
>          Range<Integer> r = Range.of(1, 2);
>          ^
>    bad class file: ./Range.class
>      method descriptor invalid for <init>
>      Please remove or make sure it appears in the correct subdirectory of the classpath.
> 1 error
>
> This came about as I was writing some inline classes and corresponding tests.
>
> So I started poking around the class file and javac code.
>
> A constructor for an inline class declares that class as the return type of method-related constants/attributes:
>
> #10 = Methodref          #1.#11         // Range."<init>":(Ljava/lang/Object;Ljava/lang/Object;)QRange;
> #11 = NameAndType        #12:#13        // "<init>":(Ljava/lang/Object;Ljava/lang/Object;)QRange;
> #12 = Utf8               <init>
> ...
> private static Range<T> Range(java.lang.Object, java.lang.Object);
>    descriptor: (Ljava/lang/Object;Ljava/lang/Object;)QRange;
> ...
>    Signature: #22                          // (Ljava/lang/Object;Ljava/lang/Object;)QRange<TT;>;
>
> For reference classes the return type is void (V).
>
>
> In javac, ClassReader.readMethod first creates a MethodType instance for ?<init>? with an explicit void return type, which gets applied to the MethodSymbol instance. Signature attribute parsing then updates the MethodSymbol?s type with the result of parsing the constructor signature attribute, thus a non-void return type appears, which then fails the method validation check.
>
>
> I bodged javac with this patch:
>
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
> @@ -2254,7 +2254,7 @@ public class ClassReader {
>           if (name == names.init && ((flags & STATIC) != 0)) {
>               flags &= ~STATIC;
>               type = new MethodType(type.getParameterTypes(),
> -                    syms.voidType,
> +                    currentOwner.isValue() ? currentOwner.type : syms.voidType,
>                       type.getThrownTypes(),
>                       syms.methodClass);
>           }
> @@ -2302,7 +2302,7 @@ public class ClassReader {
>   
>       void validateMethodType(Name name, Type t) {
>           if ((!t.hasTag(TypeTag.METHOD) && !t.hasTag(TypeTag.FORALL)) ||
> -            (name == names.init && !t.getReturnType().hasTag(TypeTag.VOID))) {
> +            (name == names.init && !currentOwner.isValue() && !t.getReturnType().hasTag(TypeTag.VOID))) {
>               throw badClassFile("method.descriptor.invalid", name);
>           }
>       }
>
> ? but I don?t really know what the implications are.
>
> Paul.


From thartmann at openjdk.java.net  Mon Dec  7 07:42:22 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 7 Dec 2020 07:42:22 GMT
Subject: [lworld] RFR: 8257773: [lworld] fix compiler replay for new
 profile data
In-Reply-To: <5mxwZcverPBXj_Fz9DcePxWp0k8-i_9u6opJ0M0VPQs=.1d6051e4-5428-4384-adb0-bbd38c5ecb43@github.com>
References: <5mxwZcverPBXj_Fz9DcePxWp0k8-i_9u6opJ0M0VPQs=.1d6051e4-5428-4384-adb0-bbd38c5ecb43@github.com>
Message-ID: <S5Ce3fXOhsVFzBTHENzt09BBXtBmljaXGTk-JXfdJYc=.7dcc8267-035d-452b-84e2-95e4c72629b8@github.com>

On Fri, 4 Dec 2020 16:54:25 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Logic is missing to handle new profile data for array loads/stores and
> acmp when a replay file is dump.

That looks good to me and explains the replay failures I was seeing. Thanks for fixing so quickly!

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

Marked as reviewed by thartmann (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/293

From roland at openjdk.java.net  Mon Dec  7 07:53:23 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 7 Dec 2020 07:53:23 GMT
Subject: [lworld] Integrated: 8257773: [lworld] fix compiler replay for new
 profile data
In-Reply-To: <5mxwZcverPBXj_Fz9DcePxWp0k8-i_9u6opJ0M0VPQs=.1d6051e4-5428-4384-adb0-bbd38c5ecb43@github.com>
References: <5mxwZcverPBXj_Fz9DcePxWp0k8-i_9u6opJ0M0VPQs=.1d6051e4-5428-4384-adb0-bbd38c5ecb43@github.com>
Message-ID: <9iCLGmIOddTfLE1qYPl0F4A3kyI8HNjAexH1fdO2Z_s=.d35651a3-4016-4999-8f52-f0bb16ff05f5@github.com>

On Fri, 4 Dec 2020 16:54:25 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Logic is missing to handle new profile data for array loads/stores and
> acmp when a replay file is dump.

This pull request has now been integrated.

Changeset: 19c23ff5
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/19c23ff5
Stats:     13 lines in 1 file changed: 13 ins; 0 del; 0 mod

8257773: [lworld] fix compiler replay for new profile data

Reviewed-by: thartmann

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

PR: https://git.openjdk.java.net/valhalla/pull/293

From thartmann at openjdk.java.net  Mon Dec  7 11:53:28 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 7 Dec 2020 11:53:28 GMT
Subject: [lworld] RFR: 8256330: [lworld] Dead inline type nodes are not
 reclaimed assertions
Message-ID: <BVxTdCWkSSof3UfHoWBmZA4bZ5a2gm_4XNwd6-UmDu8=.6438a309-1224-43a4-964c-fb4db44d07d0@github.com>

Fixed missing registration of new nodes with IGVN and re-enabled assert such that code is in sync with mainline.

Thanks,
Tobias

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

Commit messages:
 - 8256330: [lworld] Dead inline type nodes are not reclaimed assertions

Changes: https://git.openjdk.java.net/valhalla/pull/296/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=296&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256330
  Stats: 6 lines in 4 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/296.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/296/head:pull/296

PR: https://git.openjdk.java.net/valhalla/pull/296

From thartmann at openjdk.java.net  Mon Dec  7 12:14:23 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 7 Dec 2020 12:14:23 GMT
Subject: [lworld] Integrated: 8256330: [lworld] Dead inline type nodes are not
 reclaimed assertions
In-Reply-To: <BVxTdCWkSSof3UfHoWBmZA4bZ5a2gm_4XNwd6-UmDu8=.6438a309-1224-43a4-964c-fb4db44d07d0@github.com>
References: <BVxTdCWkSSof3UfHoWBmZA4bZ5a2gm_4XNwd6-UmDu8=.6438a309-1224-43a4-964c-fb4db44d07d0@github.com>
Message-ID: <ub5hEqvUxg6a71dpgbZvdzu9EZLLXsRa3EWAVyhB2Xs=.374389ae-4e62-4a7d-afad-6b61f8968b7d@github.com>

On Mon, 7 Dec 2020 11:49:10 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Fixed missing registration of new nodes with IGVN and re-enabled assert such that code is in sync with mainline.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 0d4353e3
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/0d4353e3
Stats:     6 lines in 4 files changed: 2 ins; 0 del; 4 mod

8256330: [lworld] Dead inline type nodes are not reclaimed assertions

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

PR: https://git.openjdk.java.net/valhalla/pull/296

From forax at univ-mlv.fr  Mon Dec  7 16:25:36 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 7 Dec 2020 17:25:36 +0100 (CET)
Subject: inline record ref projection contains an empty record attribute
In-Reply-To: <dd2f7811-c238-eae9-1cf7-eb4b9afd79d0@oracle.com>
References: <1017263548.2005297.1606911486680.JavaMail.zimbra@u-pem.fr>
 <dd2f7811-c238-eae9-1cf7-eb4b9afd79d0@oracle.com>
Message-ID: <1217964994.601999.1607358336991.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Srikanth" <srikanth.adayapalam at oracle.com>
> ?: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Cc: "Jim Laskey" <james.laskey at oracle.com>
> Envoy?: Lundi 7 D?cembre 2020 08:27:39
> Objet: Re: inline record ref projection contains an empty record attribute

> Hi Remi,

Hi Srikanth, hi Jim,

> 
> Thanks for the problem report.
> https://bugs.openjdk.java.net/browse/JDK-8251041 tracks the issues
> relating to inline records.
> We know of quite a few issues. (including reported by you in the past) -
> Jim is looking into these.

my main blocking point actually is that the reflection API checks if a class is a record using getSuperclass() == j.l.Record.class instead of isAssignableFrom (or mark all classes that inherits directly or indirectly from java.lang.Record if perf is an issue).

> 
> Srikanth

R?mi

> 
> On 02/12/20 5:48 pm, Remi Forax wrote:
>> Hi all,
>> using this inline record
>>
>> public @__inline__ record IntBox(int value) {}
>>
>> When the compiler generates the ref projection, IntBox$Ref, an empty attribute
>> "Record" is generated which i believe is a mistake.
>> The ref projection should not contains that attribute at all.
>>
>> regards,
>> R?mi
>>
>> ---
>> Classfile
>> /home/forax/git/transmogrif/target/classes/fr/umlv/transmogrif/IntBox$ref.class
>>    Last modified Dec 2, 2020; size 222 bytes
>>    SHA-256 checksum
>>    2ee826fe2e8735044ea2a7f9e766aa101a7786385b5d27291864e7e4d550d6e2
>>    Compiled from "IntBox.java"
>> public abstract class fr.umlv.transmogrif.IntBox$ref extends java.lang.Record
>>    minor version: 0
>>    major version: 60
>>    flags: (0x0421) ACC_PUBLIC, ACC_SUPER, ACC_ABSTRACT
>>    this_class: #1                          // fr/umlv/transmogrif/IntBox$ref
>>    super_class: #3                         // java/lang/Record
>>    interfaces: 0, fields: 0, methods: 0, attributes: 4
>> Constant pool:
>>     #1 = Class              #2             // fr/umlv/transmogrif/IntBox$ref
>>     #2 = Utf8               fr/umlv/transmogrif/IntBox$ref
>>     #3 = Class              #4             // java/lang/Record
>>     #4 = Utf8               java/lang/Record
>>     #5 = Utf8               SourceFile
>>     #6 = Utf8               IntBox.java
>>     #7 = Utf8               NestMembers
>>     #8 = Class              #9             // fr/umlv/transmogrif/IntBox
>>     #9 = Utf8               fr/umlv/transmogrif/IntBox
>>    #10 = Utf8               Record
>>    <------------ oops
>>    #11 = Utf8               PermittedSubclasses
>> {
>> }
>> SourceFile: "IntBox.java"
>> NestMembers:
>>    fr/umlv/transmogrif/IntBox
>> PermittedSubclasses:
>>    fr/umlv/transmogrif/IntBox
>> Record:
>> [forax at localhost transmogrif]$ javap -private -c -verbose
>> target/classes/fr/umlv/transmogrif/IntBox\$ref.class
>> Classfile
>> /home/forax/git/transmogrif/target/classes/fr/umlv/transmogrif/IntBox$ref.class
>>    Last modified Dec 2, 2020; size 222 bytes
>>    SHA-256 checksum
>>    2ee826fe2e8735044ea2a7f9e766aa101a7786385b5d27291864e7e4d550d6e2
>>    Compiled from "IntBox.java"
>> public abstract class fr.umlv.transmogrif.IntBox$ref extends java.lang.Record
>>    minor version: 0
>>    major version: 60
>>    flags: (0x0421) ACC_PUBLIC, ACC_SUPER, ACC_ABSTRACT
>>    this_class: #1                          // fr/umlv/transmogrif/IntBox$ref
>>    super_class: #3                         // java/lang/Record
>>    interfaces: 0, fields: 0, methods: 0, attributes: 4
>> Constant pool:
>>     #1 = Class              #2             // fr/umlv/transmogrif/IntBox$ref
>>     #2 = Utf8               fr/umlv/transmogrif/IntBox$ref
>>     #3 = Class              #4             // java/lang/Record
>>     #4 = Utf8               java/lang/Record
>>     #5 = Utf8               SourceFile
>>     #6 = Utf8               IntBox.java
>>     #7 = Utf8               NestMembers
>>     #8 = Class              #9             // fr/umlv/transmogrif/IntBox
>>     #9 = Utf8               fr/umlv/transmogrif/IntBox
>>    #10 = Utf8               Record
>>    #11 = Utf8               PermittedSubclasses
>> {
>> }
>> SourceFile: "IntBox.java"
>> NestMembers:
>>    fr/umlv/transmogrif/IntBox
>> PermittedSubclasses:
>>    fr/umlv/transmogrif/IntBox
>> Record:                                 <------------------------ oops

From chris.hegarty at oracle.com  Mon Dec  7 16:56:58 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 7 Dec 2020 16:56:58 +0000
Subject: inline record ref projection contains an empty record attribute
In-Reply-To: <1217964994.601999.1607358336991.JavaMail.zimbra@u-pem.fr>
References: <1017263548.2005297.1606911486680.JavaMail.zimbra@u-pem.fr>
 <dd2f7811-c238-eae9-1cf7-eb4b9afd79d0@oracle.com>
 <1217964994.601999.1607358336991.JavaMail.zimbra@u-pem.fr>
Message-ID: <F1C42958-11E9-4FDB-9DFF-20BE422B1F13@oracle.com>

Remi,

> On 7 Dec 2020, at 16:25, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> ----- Mail original -----
>> De: "Srikanth" <srikanth.adayapalam at oracle.com>
>> ?: "valhalla-dev" <valhalla-dev at openjdk.java.net>
>> Cc: "Jim Laskey" <james.laskey at oracle.com>
>> Envoy?: Lundi 7 D?cembre 2020 08:27:39
>> Objet: Re: inline record ref projection contains an empty record attribute
> 
>> Hi Remi,
> 
> Hi Srikanth, hi Jim,
> 
>> 
>> Thanks for the problem report.
>> https://bugs.openjdk.java.net/browse/JDK-8251041 tracks the issues
>> relating to inline records.
>> We know of quite a few issues. (including reported by you in the past) -
>> Jim is looking into these.
> 
> my main blocking point actually is that the reflection API checks if a class is a record using getSuperclass() == j.l.Record.class

I do not have a reference to hand, but the requirement for Class::isRecord to check that j.l.Record is a the direct superclass was requested during one of the umbrella records CSRs. There was a concern that the reflective APIs could be ?fooled? into thinking that a particular j.l.Class is a record class when it is in fact largely not in a record class, as outlined by the JLS.

> instead of isAssignableFrom (or mark all classes that inherits directly or indirectly from java.lang.Record if perf is an issue).

If isAssignableFrom is sufficient ( now that isRecord asserts finalness ), then maybe both the JLS and reflection should be updated. It might be best to bring this up on the Amber list.

-Chris.

From forax at univ-mlv.fr  Mon Dec  7 17:13:22 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 7 Dec 2020 18:13:22 +0100 (CET)
Subject: inline record ref projection contains an empty record attribute
In-Reply-To: <F1C42958-11E9-4FDB-9DFF-20BE422B1F13@oracle.com>
References: <1017263548.2005297.1606911486680.JavaMail.zimbra@u-pem.fr>
 <dd2f7811-c238-eae9-1cf7-eb4b9afd79d0@oracle.com>
 <1217964994.601999.1607358336991.JavaMail.zimbra@u-pem.fr>
 <F1C42958-11E9-4FDB-9DFF-20BE422B1F13@oracle.com>
Message-ID: <61627502.648848.1607361202507.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Chris Hegarty" <chris.hegarty at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Srikanth" <srikanth.adayapalam at oracle.com>, "Jim Laskey" <james.laskey at oracle.com>, "valhalla-dev"
> <valhalla-dev at openjdk.java.net>
> Envoy?: Lundi 7 D?cembre 2020 17:56:58
> Objet: Re: inline record ref projection contains an empty record attribute

> Remi,
> 
>> On 7 Dec 2020, at 16:25, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> ----- Mail original -----
>>> De: "Srikanth" <srikanth.adayapalam at oracle.com>
>>> ?: "valhalla-dev" <valhalla-dev at openjdk.java.net>
>>> Cc: "Jim Laskey" <james.laskey at oracle.com>
>>> Envoy?: Lundi 7 D?cembre 2020 08:27:39
>>> Objet: Re: inline record ref projection contains an empty record attribute
>> 
>>> Hi Remi,
>> 
>> Hi Srikanth, hi Jim,
>> 
>>> 
>>> Thanks for the problem report.
>>> https://bugs.openjdk.java.net/browse/JDK-8251041 tracks the issues
>>> relating to inline records.
>>> We know of quite a few issues. (including reported by you in the past) -
>>> Jim is looking into these.
>> 
>> my main blocking point actually is that the reflection API checks if a class is
>> a record using getSuperclass() == j.l.Record.class
> 
> I do not have a reference to hand, but the requirement for Class::isRecord to
> check that j.l.Record is a the direct superclass was requested during one of
> the umbrella records CSRs. There was a concern that the reflective APIs could
> be ?fooled? into thinking that a particular j.l.Class is a record class when it
> is in fact largely not in a record class, as outlined by the JLS.

Checking the direct super class is fine now, until we have inline record, because for an inline record, j.l.Record is not the direct superclass.
I suppose the question is should the record reflection spec be changed now or later when Valhalla is ready.
My guess is that we have same issue with java.lang.Enum if you want an inline enum, j.l.Enum can be the 3rd superclass,
so it's may be better to change that as part of Valhalla and not as part of Amber.

> 
>> instead of isAssignableFrom (or mark all classes that inherits directly or
>> indirectly from java.lang.Record if perf is an issue).
> 
> If isAssignableFrom is sufficient ( now that isRecord asserts finalness ), then
> maybe both the JLS and reflection should be updated. It might be best to bring
> this up on the Amber list.

I did, on valhalla list and not amber list.

> 
> -Chris.

R?mi

From paul.sandoz at oracle.com  Mon Dec  7 18:22:00 2020
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 7 Dec 2020 10:22:00 -0800
Subject: Issue with separate compilation and a generic inline type
In-Reply-To: <6603656c-3c21-db65-97ad-df7d6dc4002e@oracle.com>
References: <1B949771-9070-4E8F-B28E-5D5B59A4EF8F@oracle.com>
 <6603656c-3c21-db65-97ad-df7d6dc4002e@oracle.com>
Message-ID: <1FC71393-C431-4BA8-82A9-528AD637B4AE@oracle.com>

Hi Srikanth,

Certainly, see here https://bugs.openjdk.java.net/browse/JDK-8257846 <https://bugs.openjdk.java.net/browse/JDK-8257846>

Paul

> On Dec 6, 2020, at 11:37 PM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
> 
> Hi Paul,
> 
> May I request you to raise a JBS ticket ? I will follow up - TIA.
> 
> Srikanth
> 
> On 05/12/20 6:41 am, Paul Sandoz wrote:
>> Hi,
>> 
>> If I have this inline class and a test class
>> 
>> public inline class Range<T> {
>>     private final T lower;
>>     private final T upper;
>> 
>>     private Range(T lower, T upper) {
>>         this.lower = lower;
>>         this.upper = upper;
>>     }
>> 
>>     public static <T> Range<T> of(T lower, T upper) {
>>         return new Range<>(lower, upper);
>>     }
>> }
>> 
>> public class Test {
>>     public static void main(String[] args) {
>>         Range<Integer> r = Range.of(1, 2);
>>     }
>> }
>> 
>> Compiling Range first and then, separately, Test fails:
>> 
>> 
>> $ javac Range.java
>> $ javac Test.java
>> Test.java:3: error: cannot access Range
>>         Range<Integer> r = Range.of(1, 2);
>>         ^
>>   bad class file: ./Range.class
>>     method descriptor invalid for <init>
>>     Please remove or make sure it appears in the correct subdirectory of the classpath.
>> 1 error
>> 
>> This came about as I was writing some inline classes and corresponding tests.
>> 
>> So I started poking around the class file and javac code.
>> 
>> A constructor for an inline class declares that class as the return type of method-related constants/attributes:
>> 
>> #10 = Methodref          #1.#11         // Range."<init>":(Ljava/lang/Object;Ljava/lang/Object;)QRange;
>> #11 = NameAndType        #12:#13        // "<init>":(Ljava/lang/Object;Ljava/lang/Object;)QRange;
>> #12 = Utf8               <init>
>> ...
>> private static Range<T> Range(java.lang.Object, java.lang.Object);
>>   descriptor: (Ljava/lang/Object;Ljava/lang/Object;)QRange;
>> ...
>>   Signature: #22                          // (Ljava/lang/Object;Ljava/lang/Object;)QRange<TT;>;
>> 
>> For reference classes the return type is void (V).
>> 
>> 
>> In javac, ClassReader.readMethod first creates a MethodType instance for ?<init>? with an explicit void return type, which gets applied to the MethodSymbol instance. Signature attribute parsing then updates the MethodSymbol?s type with the result of parsing the constructor signature attribute, thus a non-void return type appears, which then fails the method validation check.
>> 
>> 
>> I bodged javac with this patch:
>> 
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
>> @@ -2254,7 +2254,7 @@ public class ClassReader {
>>          if (name == names.init && ((flags & STATIC) != 0)) {
>>              flags &= ~STATIC;
>>              type = new MethodType(type.getParameterTypes(),
>> -                    syms.voidType,
>> +                    currentOwner.isValue() ? currentOwner.type : syms.voidType,
>>                      type.getThrownTypes(),
>>                      syms.methodClass);
>>          }
>> @@ -2302,7 +2302,7 @@ public class ClassReader {
>>        void validateMethodType(Name name, Type t) {
>>          if ((!t.hasTag(TypeTag.METHOD) && !t.hasTag(TypeTag.FORALL)) ||
>> -            (name == names.init && !t.getReturnType().hasTag(TypeTag.VOID))) {
>> +            (name == names.init && !currentOwner.isValue() && !t.getReturnType().hasTag(TypeTag.VOID))) {
>>              throw badClassFile("method.descriptor.invalid", name);
>>          }
>>      }
>> 
>> ? but I don?t really know what the implications are.
>> 
>> Paul.
> 


From thartmann at openjdk.java.net  Tue Dec  8 11:19:26 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 8 Dec 2020 11:19:26 GMT
Subject: [lworld] RFR: 8257832: [lworld] C2 compilation fails with
 assert(_base == AryPtr) failed: Not an array pointer
Message-ID: <dPcMmEttu08EPhcy4uMo8ivDXCU-o7JyESTLJYFL7S8=.e5025d7f-5243-4654-81a1-d24a764723d8@github.com>

When the array load/store type profile is polluted, it may contradict static array type information and as a result we always trap when using it speculatively. We hit the assert or crash because control/data unexpectedly becomes `top`.

Similar to `Parse::array_store_check()`, we should not use profile information in `Parse::array_addressing` if it contradicts static type information.

Thanks,
Tobias

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

Commit messages:
 - 8257832: [lworld] C2 compilation fails with assert(_base == AryPtr) failed: Not an array pointer

Changes: https://git.openjdk.java.net/valhalla/pull/297/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=297&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257832
  Stats: 97 lines in 3 files changed: 69 ins; 17 del; 11 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/297.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/297/head:pull/297

PR: https://git.openjdk.java.net/valhalla/pull/297

From thartmann at openjdk.java.net  Tue Dec  8 11:53:26 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 8 Dec 2020 11:53:26 GMT
Subject: [lworld] Integrated: 8257832: [lworld] C2 compilation fails with
 assert(_base == AryPtr) failed: Not an array pointer
In-Reply-To: <dPcMmEttu08EPhcy4uMo8ivDXCU-o7JyESTLJYFL7S8=.e5025d7f-5243-4654-81a1-d24a764723d8@github.com>
References: <dPcMmEttu08EPhcy4uMo8ivDXCU-o7JyESTLJYFL7S8=.e5025d7f-5243-4654-81a1-d24a764723d8@github.com>
Message-ID: <uWd2yk5FfbTMF7wVwvFfqUdGVe2jSLamrGBwIoVmXEc=.2b6b6963-dab9-43c5-872b-16c2c5fd2090@github.com>

On Tue, 8 Dec 2020 11:15:36 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> When the array load/store type profile is polluted, it may contradict static array type information and as a result we always trap when using it speculatively. We hit the assert or crash because control/data unexpectedly becomes `top`.
> 
> Similar to `Parse::array_store_check()`, we should not use profile information in `Parse::array_addressing` if it contradicts static type information.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 71816896
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/71816896
Stats:     97 lines in 3 files changed: 69 ins; 17 del; 11 mod

8257832: [lworld] C2 compilation fails with assert(_base == AryPtr) failed: Not an array pointer

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

PR: https://git.openjdk.java.net/valhalla/pull/297

From thartmann at openjdk.java.net  Tue Dec  8 13:55:29 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 8 Dec 2020 13:55:29 GMT
Subject: [lworld] RFR: 8257579: [lworld] C2 compilation fails because
 ret_addr_offset() is not within emitted code
Message-ID: <bBA1Vd5j8jGgy-D04Tkj0CZZ3ahSfjnghJe3jmb6msM=.32a1ef4f-272e-47ab-8dc0-b93f0e4970b7@github.com>

`PhaseMacroExpand::expand_mh_intrinsic_return` emits a `CallLeafNoFPNode` with `_enty_point == NULL` which is mapped to an indirect call. The instruction size in `MachCallRuntimeNode::ret_addr_offset` needs to be adjusted accordingly.

Thanks,
Tobias

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

Commit messages:
 - 8257579: [lworld] C2 compilation fails because ret_addr_offset() is not within emitted code

Changes: https://git.openjdk.java.net/valhalla/pull/298/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=298&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257579
  Stats: 7 lines in 2 files changed: 5 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/298.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/298/head:pull/298

PR: https://git.openjdk.java.net/valhalla/pull/298

From thartmann at openjdk.java.net  Tue Dec  8 14:53:28 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 8 Dec 2020 14:53:28 GMT
Subject: [lworld] Integrated: 8257579: [lworld] C2 compilation fails because
 ret_addr_offset() is not within emitted code
In-Reply-To: <bBA1Vd5j8jGgy-D04Tkj0CZZ3ahSfjnghJe3jmb6msM=.32a1ef4f-272e-47ab-8dc0-b93f0e4970b7@github.com>
References: <bBA1Vd5j8jGgy-D04Tkj0CZZ3ahSfjnghJe3jmb6msM=.32a1ef4f-272e-47ab-8dc0-b93f0e4970b7@github.com>
Message-ID: <KbnMq9gegw2PVh8q-D1lgoJK6L96XAQEUSiq2pxWcYQ=.f3a6d27e-a054-4a07-bb33-f6d639f75fe8@github.com>

On Tue, 8 Dec 2020 13:50:41 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> `PhaseMacroExpand::expand_mh_intrinsic_return` emits a `CallLeafNoFPNode` with `_enty_point == NULL` which is mapped to an indirect call. The instruction size in `MachCallRuntimeNode::ret_addr_offset` needs to be adjusted accordingly.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 1a7dcb4e
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/1a7dcb4e
Stats:     7 lines in 2 files changed: 5 ins; 2 del; 0 mod

8257579: [lworld] C2 compilation fails because ret_addr_offset() is not within emitted code

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

PR: https://git.openjdk.java.net/valhalla/pull/298

From thartmann at openjdk.java.net  Wed Dec  9 14:28:57 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 9 Dec 2020 14:28:57 GMT
Subject: [lworld] RFR: 8257965: [lworld] C2 compilation fails with
 assert(unc->peek_monitor_obj() == obj) failed: wrong monitor
Message-ID: <jGYJbIAcR03AnXtGAAf6RlStkTRjWN_fK9rboJa7W6c=.d112c22e-0c3c-4221-b58f-60bfd42d84b7@github.com>

The assert is too strong because when locking on an object that became known to be an inline type only after parsing, C2 might have scalarized `peek_monitor_obj()` in the debug info of the uncommon trap. I've adjusted the assert but found another problem while writing tests: C2 can eliminate a lock even if the type is not statically known (and therefore could be an inline type) as long as Escape Analysis is able to prove that he object is non-escaping (see `TestLWorld::test133`). We need to add an inline type check to `PhaseMacroExpand::eliminate_locking_node` as well.

Thanks,
Tobias

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

Commit messages:
 - 8257965: [lworld] C2 compilation fails with assert(unc->peek_monitor_obj() == obj) failed: wrong monitor

Changes: https://git.openjdk.java.net/valhalla/pull/299/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=299&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257965
  Stats: 202 lines in 7 files changed: 144 ins; 42 del; 16 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/299.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/299/head:pull/299

PR: https://git.openjdk.java.net/valhalla/pull/299

From thartmann at openjdk.java.net  Wed Dec  9 15:09:02 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 9 Dec 2020 15:09:02 GMT
Subject: [lworld] RFR: 8257965: [lworld] C2 compilation fails with
 assert(unc->peek_monitor_obj() == obj) failed: wrong monitor [v2]
In-Reply-To: <jGYJbIAcR03AnXtGAAf6RlStkTRjWN_fK9rboJa7W6c=.d112c22e-0c3c-4221-b58f-60bfd42d84b7@github.com>
References: <jGYJbIAcR03AnXtGAAf6RlStkTRjWN_fK9rboJa7W6c=.d112c22e-0c3c-4221-b58f-60bfd42d84b7@github.com>
Message-ID: <Wgn7_Gb06kjUw9a28qHC4wS0Hzr6sKHAQFwwkm4SiVE=.573d7ee0-a596-4dca-a21b-a097a94f58b7@github.com>

> The assert is too strong because when locking on an object that became known to be an inline type only after parsing, C2 might have scalarized `peek_monitor_obj()` in the debug info of the uncommon trap. I've adjusted the assert but found another problem while writing tests: C2 can eliminate a lock even if the type is not statically known (and therefore could be an inline type) as long as Escape Analysis is able to prove that he object is non-escaping (see `TestLWorld::test133`). We need to add an inline type check to `PhaseMacroExpand::eliminate_locking_node` as well.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Removed too strong assert

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

Changes:
  - all: https://git.openjdk.java.net/valhalla/pull/299/files
  - new: https://git.openjdk.java.net/valhalla/pull/299/files/f695337d..677db0ae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=299&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=299&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/299.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/299/head:pull/299

PR: https://git.openjdk.java.net/valhalla/pull/299

From thartmann at openjdk.java.net  Thu Dec 10 07:54:49 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 10 Dec 2020 07:54:49 GMT
Subject: [lworld] Integrated: 8257965: [lworld] C2 compilation fails with
 assert(unc->peek_monitor_obj() == obj) failed: wrong monitor
In-Reply-To: <jGYJbIAcR03AnXtGAAf6RlStkTRjWN_fK9rboJa7W6c=.d112c22e-0c3c-4221-b58f-60bfd42d84b7@github.com>
References: <jGYJbIAcR03AnXtGAAf6RlStkTRjWN_fK9rboJa7W6c=.d112c22e-0c3c-4221-b58f-60bfd42d84b7@github.com>
Message-ID: <wEazrEI2ozIeDZhHZcj0HYQopuKuwamjRKuCsVk8Ny4=.f23ef442-bdff-4e53-a1db-3abab699ecf6@github.com>

On Wed, 9 Dec 2020 14:24:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The assert is too strong because when locking on an object that became known to be an inline type only after parsing, C2 might have scalarized `peek_monitor_obj()` in the debug info of the uncommon trap. I've adjusted the assert but found another problem while writing tests: C2 can eliminate a lock even if the type is not statically known (and therefore could be an inline type) as long as Escape Analysis is able to prove that he object is non-escaping (see `TestLWorld::test133`). We need to add an inline type check to `PhaseMacroExpand::eliminate_locking_node` as well.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 6d1ca782
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/6d1ca782
Stats:     201 lines in 7 files changed: 143 ins; 42 del; 16 mod

8257965: [lworld] C2 compilation fails with assert(unc->peek_monitor_obj() == obj) failed: wrong monitor

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

PR: https://git.openjdk.java.net/valhalla/pull/299

From sirinath1978m at gmail.com  Thu Dec 10 09:00:51 2020
From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena)
Date: Thu, 10 Dec 2020 14:30:51 +0530
Subject: Common Super Type for Boxed Types and Array Types
Message-ID: <CAAfFNYF3uZ6oTmPECbH0zjpg9FAQHjBrVG7BCb2P2Yd9qgegpw@mail.gmail.com>

Hello,

Some of the boxed types device directly from Object. Also, the array types
derive from Object.

This is sometimes inconvenient when pacifying API signatures and bounds.

So is it possible to consider a hierarchy like:
- BoxedPrimitive
  - Number
    - Integer
    - ...
  - Boolean
  - Character
- Array
  - PrimitiveArray
    - NumberArray
      - int[]
      - ...
  - boolean[]
  - character[]
  - ObjectArray<T>

Suminda

From thartmann at openjdk.java.net  Thu Dec 10 09:35:55 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 10 Dec 2020 09:35:55 GMT
Subject: [lworld] RFR: 8258026: [lworld] Endless deoptimization at
 defaultvalue due to unresolved klass
Message-ID: <LNznucQMrTzfTzFzyJvKzHyEtbIi8HPQSH_GJx3ORgg=.64a7ec3b-4f2f-4b64-aea4-c2fb65091e45@github.com>

Similar to `new`, C2's typeflow analysis should trap if the klass is unresolved at `defaultvalue`.

Thanks,
Tobias

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

Commit messages:
 - 8258026: [lworld] Endless deoptimization at defaultvalue due to unresolved klass

Changes: https://git.openjdk.java.net/valhalla/pull/300/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=300&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258026
  Stats: 10 lines in 2 files changed: 0 ins; 8 del; 2 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/300.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/300/head:pull/300

PR: https://git.openjdk.java.net/valhalla/pull/300

From sirinath1978m at gmail.com  Thu Dec 10 10:20:53 2020
From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena)
Date: Thu, 10 Dec 2020 15:50:53 +0530
Subject: Common Super Type for Boxed Types and Array Types
In-Reply-To: <CAAfFNYF3uZ6oTmPECbH0zjpg9FAQHjBrVG7BCb2P2Yd9qgegpw@mail.gmail.com>
References: <CAAfFNYF3uZ6oTmPECbH0zjpg9FAQHjBrVG7BCb2P2Yd9qgegpw@mail.gmail.com>
Message-ID: <CAAfFNYG7_xAoa+dhshn7-02_jESK7ozTcVep0jAc-aZ+UQTrMA@mail.gmail.com>

Hello,

Correcting some typos in my previous email.

Some of the boxed types device directly from Object. Also, the array types
derive from Object.

This is sometimes inconvenient when pacifying API signatures and bounds.

So is it possible to consider a hierarchy like:

- Any???
  - Object
    - Boxed<T>
      - BoxedPrimitive<T>
        - Number<T>
          - Integer
          - ...
        - Boolean
        - Character
     - BoxedValueType<T> // or BoxedValue<T>
    - Array<T>
      - ArrayPrimitive<T>
        - ArrayNumber<T>
          - int[]
          - ...
        - boolean[]
        - character[]
      - ArrayObject<T>
  - Value // May have another name
    - ValuePrimitive<T> // T when there are primitive generics in the
language
      - ValueNumber<T>
        - int
        - ...
      - boolean
      - char

Suminda

>

From thartmann at openjdk.java.net  Thu Dec 10 11:17:41 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 10 Dec 2020 11:17:41 GMT
Subject: git: openjdk/valhalla: lworld: 8258026: [lworld] Endless
 deoptimization at defaultvalue due to unresolved klass
Message-ID: <c10b233c-11c3-4cc0-be81-91c79b778e13@openjdk.org>

Changeset: 1d85945f
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2020-12-10 11:17:03 +0000
URL:       https://git.openjdk.java.net/valhalla/commit/1d85945f

8258026: [lworld] Endless deoptimization at defaultvalue due to unresolved klass

! src/hotspot/share/ci/ciTypeFlow.cpp
! src/hotspot/share/opto/parseHelper.cpp


From thartmann at openjdk.java.net  Thu Dec 10 11:19:47 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 10 Dec 2020 11:19:47 GMT
Subject: [lworld] Integrated: 8258026: [lworld] Endless deoptimization at
 defaultvalue due to unresolved klass
In-Reply-To: <LNznucQMrTzfTzFzyJvKzHyEtbIi8HPQSH_GJx3ORgg=.64a7ec3b-4f2f-4b64-aea4-c2fb65091e45@github.com>
References: <LNznucQMrTzfTzFzyJvKzHyEtbIi8HPQSH_GJx3ORgg=.64a7ec3b-4f2f-4b64-aea4-c2fb65091e45@github.com>
Message-ID: <amfr4S-lJVd6EKZdy1B4LzP0j9V7-FKwZ9bpb7pDMSw=.2beb77a4-b1d2-44ab-84ef-23711b6e96fd@github.com>

On Thu, 10 Dec 2020 09:31:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Similar to `new`, C2's typeflow analysis should trap if the klass is unresolved at `defaultvalue`.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 1d85945f
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/1d85945f
Stats:     10 lines in 2 files changed: 0 ins; 8 del; 2 mod

8258026: [lworld] Endless deoptimization at defaultvalue due to unresolved klass

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

PR: https://git.openjdk.java.net/valhalla/pull/300

From brian.goetz at oracle.com  Thu Dec 10 15:10:44 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 10 Dec 2020 10:10:44 -0500
Subject: Common Super Type for Boxed Types and Array Types
In-Reply-To: <CAAfFNYF3uZ6oTmPECbH0zjpg9FAQHjBrVG7BCb2P2Yd9qgegpw@mail.gmail.com>
References: <CAAfFNYF3uZ6oTmPECbH0zjpg9FAQHjBrVG7BCb2P2Yd9qgegpw@mail.gmail.com>
Message-ID: <c45955fe-88de-368c-90d8-19563c2fe8b2@oracle.com>

Modeling numerics with real programming languages is hard, and any given 
language's attempt will surely have something to hate.? (Computer 
numbers are not like math numbers; the integers form a well-ordered 
field, but computer integers do not respect things like "if a > 0, then 
a+b > b".)

Your particular proposal falls down in that a Number need not be a 
Primitive Box; what about BigInteger?? (Now that we have sealed types, 
it would be possible to introduce a sealed _interface_ for the eight box 
types, but that would not be practical until sealed types exits preview.)

The array types are a bigger problem, but because the array types are 
built into the JVM rather than classfiles generated by the java 
compiler, retrofitting new supertypes is several orders of magnitude 
more expensive.? And a far bigger problem is the lack of array 
covariance; that while Integer[] is a subtype of Object[], int[] is 
not.? This means that a supertype like `ArrayPrimitive<T>` is not as 
useful as it looks, as there is no common supertype (other than Object) 
to erase to.

Bottom line: this is all a lot more complicated than it looks.

Cheers,
-Brian

On 12/10/2020 4:00 AM, Suminda Sirinath Salpitikorala Dharmasena wrote:
> Hello,
>
> Some of the boxed types device directly from Object. Also, the array types
> derive from Object.
>
> This is sometimes inconvenient when pacifying API signatures and bounds.
>
> So is it possible to consider a hierarchy like:
> - BoxedPrimitive
>    - Number
>      - Integer
>      - ...
>    - Boolean
>    - Character
> - Array
>    - PrimitiveArray
>      - NumberArray
>        - int[]
>        - ...
>    - boolean[]
>    - character[]
>    - ObjectArray<T>
>
> Suminda


From thartmann at openjdk.java.net  Fri Dec 11 13:11:22 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 11 Dec 2020 13:11:22 GMT
Subject: [lworld] RFR: 8228634: [lworld] ciField::will_link() returns
 incorrect result for the withfield bytecode
Message-ID: <uFKQSMNwZzGv4duG5ZmPPf90T_xjg6g5bRujoqgkzfI=.e7b02780-7bca-4285-ad4d-6f7137e1ae04@github.com>

In `GraphBuilder::withfield`, `ciField::will_link()` can return false even if the holder klass is loaded (see bug comments). In that case we should not deoptimize but patch the store instruction that writes the new field value. That is required even if the field offset is known because the field could not be accessible/available and we would need to throw an exception during patching. The load/store instructions emitted by `copy_inline_content` to initialize the fields of the new inline type buffer copy should never require patching: We know their offsets (because the holder is loaded) and we don't need to check access restrictions.

Unrelated changes:
- Array loads should not be delayed if the subsequent getfield requires patching (see changes to `GraphBuilder::load_indexed`)
- Replaced the `WithField` and `DefaultValue` IR nodes by a `Deoptimize` node
- Refactoring and removal of dead code

Thanks,
Tobias

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

Commit messages:
 - Should save state before popping from stack
 - 8228634: [lworld] ciField::will_link() returns incorrect result for the withfield bytecode

Changes: https://git.openjdk.java.net/valhalla/pull/301/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=301&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8228634
  Stats: 191 lines in 15 files changed: 30 ins; 97 del; 64 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/301.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/301/head:pull/301

PR: https://git.openjdk.java.net/valhalla/pull/301

From fparain at openjdk.java.net  Fri Dec 11 15:16:10 2020
From: fparain at openjdk.java.net (Frederic Parain)
Date: Fri, 11 Dec 2020 15:16:10 GMT
Subject: [lworld] RFR: 8228634: [lworld] ciField::will_link() returns
 incorrect result for the withfield bytecode
In-Reply-To: <uFKQSMNwZzGv4duG5ZmPPf90T_xjg6g5bRujoqgkzfI=.e7b02780-7bca-4285-ad4d-6f7137e1ae04@github.com>
References: <uFKQSMNwZzGv4duG5ZmPPf90T_xjg6g5bRujoqgkzfI=.e7b02780-7bca-4285-ad4d-6f7137e1ae04@github.com>
Message-ID: <w2npzoEAhqifU7xNOQJkcDOAp4S5tv8h91p5KZV9r54=.bc089d22-24b2-4399-8e6d-ef3ec9690020@github.com>

On Fri, 11 Dec 2020 12:44:57 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> In `GraphBuilder::withfield`, `ciField::will_link()` can return false even if the holder klass is loaded (see bug comments). In that case we should not deoptimize but patch the store instruction that writes the new field value. That is required even if the field offset is known because the field could not be accessible/available and we would need to throw an exception during patching. The load/store instructions emitted by `copy_inline_content` to initialize the fields of the new inline type buffer copy should never require patching: We know their offsets (because the holder is loaded) and we don't need to check access restrictions.
> 
> Unrelated changes:
> - Array loads should not be delayed if the subsequent getfield requires patching (see changes to `GraphBuilder::load_indexed`)
> - Replaced the `WithField` and `DefaultValue` IR nodes by a `Deoptimize` node
> - Refactoring and removal of dead code
> 
> Thanks,
> Tobias

Hi Tobias,

With the discussion we had off-line about nestmates, changes look good to me.

Suggestion for a future improvement: the Deoptimize node in the HIR is a very nice improvement. However, if it looks like a general purpose node in the HIR, the LIRGenerator has a hard coded deopt reason for it: "Reason_unloaded". It would be nice to have a more flexible Deoptmize node where the reason could be specified at the HIR level.

Thank you,

Fred

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

Marked as reviewed by fparain (Committer).

PR: https://git.openjdk.java.net/valhalla/pull/301

From thartmann at openjdk.java.net  Mon Dec 14 07:07:06 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 14 Dec 2020 07:07:06 GMT
Subject: [lworld] RFR: 8228634: [lworld] ciField::will_link() returns
 incorrect result for the withfield bytecode
In-Reply-To: <w2npzoEAhqifU7xNOQJkcDOAp4S5tv8h91p5KZV9r54=.bc089d22-24b2-4399-8e6d-ef3ec9690020@github.com>
References: <uFKQSMNwZzGv4duG5ZmPPf90T_xjg6g5bRujoqgkzfI=.e7b02780-7bca-4285-ad4d-6f7137e1ae04@github.com>
 <w2npzoEAhqifU7xNOQJkcDOAp4S5tv8h91p5KZV9r54=.bc089d22-24b2-4399-8e6d-ef3ec9690020@github.com>
Message-ID: <GlGVgR3hO-Ger0kWZro3FMRr4KsQ2mv0py8EqoKbUuc=.f0b741f9-3eff-42e6-9da8-ded4fa0d3e50@github.com>

On Fri, 11 Dec 2020 15:13:13 GMT, Frederic Parain <fparain at openjdk.org> wrote:

>> In `GraphBuilder::withfield`, `ciField::will_link()` can return false even if the holder klass is loaded (see bug comments). In that case we should not deoptimize but patch the store instruction that writes the new field value. That is required even if the field offset is known because the field could not be accessible/available and we would need to throw an exception during patching. The load/store instructions emitted by `copy_inline_content` to initialize the fields of the new inline type buffer copy should never require patching: We know their offsets (because the holder is loaded) and we don't need to check access restrictions.
>> 
>> Unrelated changes:
>> - Array loads should not be delayed if the subsequent getfield requires patching (see changes to `GraphBuilder::load_indexed`)
>> - Replaced the `WithField` and `DefaultValue` IR nodes by a `Deoptimize` node
>> - Refactoring and removal of dead code
>> 
>> Thanks,
>> Tobias
>
> Hi Tobias,
> 
> With the discussion we had off-line about nestmates, changes look good to me.
> 
> Suggestion for a future improvement: the Deoptimize node in the HIR is a very nice improvement. However, if it looks like a general purpose node in the HIR, the LIRGenerator has a hard coded deopt reason for it: "Reason_unloaded". It would be nice to have a more flexible Deoptmize node where the reason could be specified at the HIR level.
> 
> Thank you,
> 
> Fred

Thanks for the review Fred!

Yes, I agree that the Deoptimize node should be more generic. As we've discussed off-thread, we can address this once more reasons for deoptimization need to be supported (probably with the restricted fields prototype).

Thanks,
Tobias

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

PR: https://git.openjdk.java.net/valhalla/pull/301

From thartmann at openjdk.java.net  Mon Dec 14 07:07:07 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 14 Dec 2020 07:07:07 GMT
Subject: [lworld] Integrated: 8228634: [lworld] ciField::will_link() returns
 incorrect result for the withfield bytecode
In-Reply-To: <uFKQSMNwZzGv4duG5ZmPPf90T_xjg6g5bRujoqgkzfI=.e7b02780-7bca-4285-ad4d-6f7137e1ae04@github.com>
References: <uFKQSMNwZzGv4duG5ZmPPf90T_xjg6g5bRujoqgkzfI=.e7b02780-7bca-4285-ad4d-6f7137e1ae04@github.com>
Message-ID: <2bs4_suSNZU61MVMoRn_-e9pIyuQtrnbeyk1NZYhST0=.b488d2b9-a180-408c-ab80-71c51e338cd8@github.com>

On Fri, 11 Dec 2020 12:44:57 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> In `GraphBuilder::withfield`, `ciField::will_link()` can return false even if the holder klass is loaded (see bug comments). In that case we should not deoptimize but patch the store instruction that writes the new field value. That is required even if the field offset is known because the field could not be accessible/available and we would need to throw an exception during patching. The load/store instructions emitted by `copy_inline_content` to initialize the fields of the new inline type buffer copy should never require patching: We know their offsets (because the holder is loaded) and we don't need to check access restrictions.
> 
> Unrelated changes:
> - Array loads should not be delayed if the subsequent getfield requires patching (see changes to `GraphBuilder::load_indexed`)
> - Replaced the `WithField` and `DefaultValue` IR nodes by a `Deoptimize` node
> - Refactoring and removal of dead code
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 67f86bdb
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/67f86bdb
Stats:     191 lines in 15 files changed: 30 ins; 97 del; 64 mod

8228634: [lworld] ciField::will_link() returns incorrect result for the withfield bytecode

Reviewed-by: fparain

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

PR: https://git.openjdk.java.net/valhalla/pull/301

From thartmann at openjdk.java.net  Mon Dec 14 11:25:16 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 14 Dec 2020 11:25:16 GMT
Subject: [lworld] RFR: 8252024: [lworld] Lock ordering issue when printing
 nmethod labels
Message-ID: <tKkP0E8dgcFzWsSiNP0NBK59BmmDe_CIRb883D0Q_8o=.fc85fa79-147e-46f8-abb9-292f305f3072@github.com>

We hit an assert while printing nmethod entry point labels when attempting to create a symbol from the `SigEntry` to iterate over. The problem is that we are holding the tty lock and symbol creation also acquires certain locks. I've refactored the code to completely avoid symbol creation and also fixed an issue where names of reference argument types are not printed anymore (because we don't keep track of that in `SigEntry`). I've also removed lots of dead code leftovers from old reserved entry support in the calling convention.

Thanks,
Tobias

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

Commit messages:
 - 8252024: [lworld] Lock ordering issue when printing nmethod labels

Changes: https://git.openjdk.java.net/valhalla/pull/302/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=302&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252024
  Stats: 186 lines in 13 files changed: 34 ins; 78 del; 74 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/302.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/302/head:pull/302

PR: https://git.openjdk.java.net/valhalla/pull/302

From thartmann at openjdk.java.net  Mon Dec 14 12:26:14 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 14 Dec 2020 12:26:14 GMT
Subject: [lworld] Integrated: 8252024: [lworld] Lock ordering issue when
 printing nmethod labels
In-Reply-To: <tKkP0E8dgcFzWsSiNP0NBK59BmmDe_CIRb883D0Q_8o=.fc85fa79-147e-46f8-abb9-292f305f3072@github.com>
References: <tKkP0E8dgcFzWsSiNP0NBK59BmmDe_CIRb883D0Q_8o=.fc85fa79-147e-46f8-abb9-292f305f3072@github.com>
Message-ID: <Cu7ZQszks-2hdXJfE6wOVRd0vMhSXKbRAbPm0sOV7OQ=.89d65660-ff9d-4685-9059-047274c1cf81@github.com>

On Mon, 14 Dec 2020 11:21:29 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> We hit an assert while printing nmethod entry point labels when attempting to create a symbol from the `SigEntry` to iterate over. The problem is that we are holding the tty lock and symbol creation also acquires certain locks. I've refactored the code to completely avoid symbol creation and also fixed an issue where names of reference argument types are not printed anymore (because we don't keep track of that in `SigEntry`). I've also removed lots of dead code leftovers from old reserved entry support in the calling convention.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 34232ad1
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/34232ad1
Stats:     186 lines in 13 files changed: 34 ins; 78 del; 74 mod

8252024: [lworld] Lock ordering issue when printing nmethod labels

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

PR: https://git.openjdk.java.net/valhalla/pull/302

From thartmann at openjdk.java.net  Tue Dec 15 17:28:19 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Dec 2020 17:28:19 GMT
Subject: [lworld] RFR: 8258412: [lworld] TestArrays::test73 fails due to
 unexpected result
Message-ID: <Ggz_9H2bOjMv7uGWMxx9FVLm0nGjVbVfv5Q2XjCah7c=.5bfb078e-cc5e-4a05-824b-a99283f59c3a@github.com>

`TestArrays::test73` spuriously failed (only) with a product build. I finally figured out that with a product build the `-XX:-MonomorphicArrayCheck` flag specified by the test is ignored which is required to trigger the problem. Instead of adding yet another scenario to our tests, I've added a `PreferCommandLineFlags` option to the framework to allow overwriting scenario flags by flags set via the command line. I'll use it for testing some more flag combinations in the CI.

The root cause of the issue is that for a flat array store the `MonomorphicArrayCheck` optimization updates the array type to the exact (flat) type but does not update the corresponding element type. As a result, `elemtype->inline_klass()->is_empty()` returns true in product leading to incorrect execution and hits an assert in debug because `elemtype` is general `java.lang.Object`.

I've also fixed another issue in `Parse::array_store_check()` and added some asserts to catch similar issues earlier in the future.

Thanks,
Tobias

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

Commit messages:
 - 8258412: [lworld] TestArrays::test73 fails due to unexpected result

Changes: https://git.openjdk.java.net/valhalla/pull/303/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=303&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258412
  Stats: 80 lines in 6 files changed: 40 ins; 30 del; 10 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/303.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/303/head:pull/303

PR: https://git.openjdk.java.net/valhalla/pull/303

From thartmann at openjdk.java.net  Wed Dec 16 06:10:13 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 16 Dec 2020 06:10:13 GMT
Subject: [lworld] Integrated: 8258412: [lworld] TestArrays::test73 fails due
 to unexpected result
In-Reply-To: <Ggz_9H2bOjMv7uGWMxx9FVLm0nGjVbVfv5Q2XjCah7c=.5bfb078e-cc5e-4a05-824b-a99283f59c3a@github.com>
References: <Ggz_9H2bOjMv7uGWMxx9FVLm0nGjVbVfv5Q2XjCah7c=.5bfb078e-cc5e-4a05-824b-a99283f59c3a@github.com>
Message-ID: <hxDL5Ym72clnXeo7_bFbEP3UoYtHO36_3VOu1zLC9NQ=.1728db02-a4b0-40b7-9f30-68c39ec7fb7b@github.com>

On Tue, 15 Dec 2020 17:23:32 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> `TestArrays::test73` spuriously failed (only) with a product build. I finally figured out that with a product build the `-XX:-MonomorphicArrayCheck` flag specified by the test is ignored which is required to trigger the problem. Instead of adding yet another scenario to our tests, I've added a `PreferCommandLineFlags` option to the framework to allow overwriting scenario flags by flags set via the command line. I'll use it for testing some more flag combinations in the CI.
> 
> The root cause of the issue is that for a flat array store the `MonomorphicArrayCheck` optimization updates the array type to the exact (flat) type but does not update the corresponding element type. As a result, `elemtype->inline_klass()->is_empty()` returns true in product leading to incorrect execution and hits an assert in debug because `elemtype` is general `java.lang.Object`.
> 
> I've also fixed another issue in `Parse::array_store_check()` and added some asserts to catch similar issues earlier in the future.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 56ddef2a
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/56ddef2a
Stats:     80 lines in 6 files changed: 40 ins; 30 del; 10 mod

8258412: [lworld] TestArrays::test73 fails due to unexpected result

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

PR: https://git.openjdk.java.net/valhalla/pull/303

From thartmann at openjdk.java.net  Wed Dec 16 12:23:24 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 16 Dec 2020 12:23:24 GMT
Subject: [lworld] RFR: 8258480: [lworld] Adapter creation asserts with
 -XX:+VerifyAdapterSharing
Message-ID: <DQE3ltauWg3MOgz6lkLcgaLZ-cwaW3W76_pVEMtQBJM=.a46158eb-048c-4ec6-ab53-cf3685317bf1@github.com>

`VerifyAdapterSharing` fails because the code of two adapters with the same fingerprint is not equal. The problem is that we are accidentally creating an "only unpack receiver" c2i adapter for a static method with an inline type as only argument. As a result, the special handling in sharedRuntime.cpp:2446 does not work.

I've also refactored related code and fixed a test bug.

Thanks,
Tobias

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

Commit messages:
 - 8258480: [lworld] Adapter creation asserts with -XX:+VerifyAdapterSharing

Changes: https://git.openjdk.java.net/valhalla/pull/304/files
 Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=304&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258480
  Stats: 43 lines in 3 files changed: 6 ins; 14 del; 23 mod
  Patch: https://git.openjdk.java.net/valhalla/pull/304.diff
  Fetch: git fetch https://git.openjdk.java.net/valhalla pull/304/head:pull/304

PR: https://git.openjdk.java.net/valhalla/pull/304

From thartmann at openjdk.java.net  Wed Dec 16 13:31:15 2020
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 16 Dec 2020 13:31:15 GMT
Subject: [lworld] Integrated: 8258480: [lworld] Adapter creation asserts with
 -XX:+VerifyAdapterSharing
In-Reply-To: <DQE3ltauWg3MOgz6lkLcgaLZ-cwaW3W76_pVEMtQBJM=.a46158eb-048c-4ec6-ab53-cf3685317bf1@github.com>
References: <DQE3ltauWg3MOgz6lkLcgaLZ-cwaW3W76_pVEMtQBJM=.a46158eb-048c-4ec6-ab53-cf3685317bf1@github.com>
Message-ID: <8jzpsf0BtLrvIiV8jBCXYpzSqtVHThy9ycea09R19zk=.1d211786-3432-4695-b995-a1989147ebe2@github.com>

On Wed, 16 Dec 2020 12:19:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> `VerifyAdapterSharing` fails because the code of two adapters with the same fingerprint is not equal. The problem is that we are accidentally creating an "only unpack receiver" c2i adapter for a static method with an inline type as only argument. As a result, the special handling in sharedRuntime.cpp:2446 does not work.
> 
> I've also refactored related code and fixed a test bug.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: bfa3dd4b
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/valhalla/commit/bfa3dd4b
Stats:     43 lines in 3 files changed: 6 ins; 14 del; 23 mod

8258480: [lworld] Adapter creation asserts with -XX:+VerifyAdapterSharing

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

PR: https://git.openjdk.java.net/valhalla/pull/304