Re: RFR: 8261670: Add javadoc for the XML processing limits [v3]

[Joe Wang]

> Add the documentation for XML processing limits to module summary. The limits 
> were previously documented in Java tutorial and guide.

Joe Wang has updated the pull request incrementally with one additional commit 
since the last revision:

  s/NumericFormatException/NumberFormatException, remove default id

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2732/files
  - new: https://git.openjdk.java.net/jdk/pull/2732/files/01695074..3e555d20

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

  Stats: 20 lines in 1 file changed: 0 ins; 3 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2732.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2732/head:pull/2732

PR: https://git.openjdk.java.net/jdk/pull/2732

Re: RFR: 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now" [v2]

[Peter Levart]

On Thu, 25 Feb 2021 15:37:39 GMT, Aleksey Shipilev  wrote:

>> Attila Szegedi has refreshed the contents of this pull request, and previous 
>> commits have been removed. The incremental views will show differences 
>> compared to the previous content of the PR.
>
> The good test would be trying with all current GCs (Serial, Parallel, G1, 
> Shenandoah, ZGC):
> 
> make run-test TEST=jdk/dynalink TEST_VM_OPTS=-XX:+UseSerialGC
> 
> Also, make sure that GH actions are able to run this test. You probably need 
> to enable the workflow here -- https://github.com/szegedi/jdk/actions -- and 
> then trigger the workflow manually on your branch (or push another commit). 
> Then "Checks" tab would show the results.

> > I would like 1st to understand why the MH created in the 
> > TestLinker.convertToType is actually GCed at all.
> 
> The whole original issue was about allowing these objects to be GCd smile.
> Short story: because all data is scoped to objects created within `makeOne` 
> method.

Right, below description helped me understand the "chain of domination - i.e. 
hard references that keep the BiClassValueRoot (extends ClassValue) reachable". 
That doesn't explain fully why converters are not GC-ed as soon as the 
associated BiClassValueRoot is eligible for GC. The secret lies in the 
implementation of ClassValue...

> 
> Longer story: It is GC'd because its reachability is dominated by the 
> `DynamicLinker` object created on [line 
> 96](https://github.com/openjdk/jdk/blob/3afec32bdf49703bb3537b36248f0550caae6d87/test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java#L96).
>  It and everything it dominates (`LinkerServicesImpl` object holding the 
> `TypeConverterFactory` object holding the `BiClassValue` objects holding the 
> method handles) become garbage as soon as the method exits.

That is not entirely true. What becomes garbage is the objects leading to the 
BiClassValueRoot (extends ClassValue) instance including the BiClassValueRoot 
instance. But it is not the ClassValue instance that keeps the associated T 
value(s) reachable. The associated values are strongly reachable from the 
associated Class instances. The Class class contains an instance field of 
type ClassValueMap which is responsible for keeping the associated values. This 
answers my question why the associated converter is GCed only after 12 new 
converters are created for the same source/target type pair. It is not because 
creating new converters would cause memory pressure and consequently trigger GC 
(I tried adding explicit System.gc() calls and they did not expedite the GCing 
of the converter). It is because ClassValue logic expunges associated T 
values from Class.ClassValueMap only at times when it has to re-arrange the 
map's internal structures and that eventually happens on new inserti
 ons for the same Class instance and different ClassValue instance.

That doesn't mean type converter caching is flawed in any way. It just means 
that some converters will be retained even though they are practically not 
"reachable" any more through the mechanism of caching. That doesn't mean that 
any ClassLoader leaks are possible either.

> This works because of the pains I took in `BiClassValue` to ensure we don't 
> leak any of the infrastructural objects through implicit `this$0` outer-class 
> references into the `ClassValue`s. That allows the `ClassValue` objects to be 
> GCd and removed from the classes' class-value mapping. This ordinarily 
> doesn't happen as most `ClassValue` objects are bound to static fields, but 
> in `TypeConverterFactory` the `BiClassValue` instances are specific to the 
> `TypeConverterFactory` instance, so they are expected to be reclaimable by GC 
> if the converter factory itself goes away.
> 
> > And after that, why it is not GCed before 12 invocations to makeOne() are 
> > made.
> 
> Because GC is at liberty to delay recognizing an object is phantom reachable? 
> I don't think we need to read too much into this? Correct me if I don't see 
> something.

As described above, GC has nothing to do with this "delay". It is caused by the 
way ClassValue keeps associated values reachable from the associated Class 
instances (that appear semantically as keys, but in fact it's the other way 
arround - ClassValue instances are weakly reachable keys and Class instances 
hold the maps).

> 
> > What would be more interesting to test is to create a converter between a 
> > type loaded by a custom (child) ClassLoader and a system type. After that, 
> > release all hard references to the custom ClassLoader and see if the 
> > converter gets GC-ed as a result. WDYT?
> 
> That does sound like 
> [TypeConverterFactoryRetentionTests.testSystemLoaderToOtherLoader](https://github.com/openjdk/jdk/blob/3afec32bdf49703bb3537b36248f0550caae6d87/test/jdk/jdk/dynalink/TypeConverterFactoryRetentionTests.java#L118)
>  True, it tests whether the _class loader_ itself gets released, not the 
> converter, but the loader wo

Re: RFR: JDK-8262199: issue in jli args.c [v5]

[Matthias Baesken]

> Sonar reports a finding in args.c, where a file check is done .
> Stat performs a check on file, and later fopen is called on the file .
> 
> The coding could be slightly rewritten so that the potential issue is removed 
> (however I do not think that it is such a big issue).

Matthias Baesken has updated the pull request incrementally with one additional 
commit since the last revision:

  Replace reportAndExit

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2692/files
  - new: https://git.openjdk.java.net/jdk/pull/2692/files/39faea43..2da97d61

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2692&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2692&range=03-04

  Stats: 9 lines in 1 file changed: 2 ins; 5 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2692.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2692/head:pull/2692

PR: https://git.openjdk.java.net/jdk/pull/2692

Re: RFR: JDK-8262199: issue in jli args.c [v3]

[Matthias Baesken]

On Thu, 25 Feb 2021 17:46:42 GMT, Christoph Langer  wrote:

>> I think that did not work because it does not fit the param types of 
>> reportAndExit but I can simplify it otherwise.
>
> Ah, I see.
> Maybe it's a bit bike-sheddy but as you're using reportAndExit only twice 
> now, wouldn't it be less convoluted if you use
> JLI_ReportMessage(...);
> exit(1);
> inline in both places?

Yes I agree,  see my latest change.

-

PR: https://git.openjdk.java.net/jdk/pull/2692

Re: RFR: JDK-8262199: issue in jli args.c [v5]

[Christoph Langer]

On Fri, 26 Feb 2021 08:31:00 GMT, Matthias Baesken  wrote:

>> Sonar reports a finding in args.c, where a file check is done .
>> Stat performs a check on file, and later fopen is called on the file .
>> 
>> The coding could be slightly rewritten so that the potential issue is 
>> removed (however I do not think that it is such a big issue).
>
> Matthias Baesken has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Replace reportAndExit

Looks good now :)

-

Marked as reviewed by clanger (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2692

Re: RFR: JDK-8262199: issue in jli args.c [v5]

[Alan Bateman]

On Fri, 26 Feb 2021 08:31:00 GMT, Matthias Baesken  wrote:

>> Sonar reports a finding in args.c, where a file check is done .
>> Stat performs a check on file, and later fopen is called on the file .
>> 
>> The coding could be slightly rewritten so that the potential issue is 
>> removed (however I do not think that it is such a big issue).
>
> Matthias Baesken has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Replace reportAndExit

This version looks good too.

-

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2692

Integrated: JDK-8262199: issue in jli args.c

[Matthias Baesken]

On Tue, 23 Feb 2021 13:58:03 GMT, Matthias Baesken  wrote:

> Sonar reports a finding in args.c, where a file check is done .
> Stat performs a check on file, and later fopen is called on the file .
> 
> The coding could be slightly rewritten so that the potential issue is removed 
> (however I do not think that it is such a big issue).

This pull request has now been integrated.

Changeset: d7efb4cc
Author:Matthias Baesken 
URL:   https://git.openjdk.java.net/jdk/commit/d7efb4cc
Stats: 25 lines in 1 file changed: 8 ins; 15 del; 2 mod

8262199: issue in jli args.c

Reviewed-by: clanger, alanb

-

PR: https://git.openjdk.java.net/jdk/pull/2692

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v19]

[Anton Kozlov]

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and 
> windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks 
> JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary 
> adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), 
> required on macOS/AArch64 platform. It's implemented with 
> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a 
> thread, so W^X mode change relates to the java thread state change (for java 
> threads). In most cases, JVM executes in write-only mode, except when calling 
> a generated stub like SafeFetch, which requires a temporary switch to 
> execute-only mode. The same execute-only mode is enabled when a java thread 
> executes in java or native states. This approach of managing W^X mode turned 
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge 
or a rebase. The pull request now contains 89 commits:

 - Merge branch 'master' into jdk-macos
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Re-do safefetch.hpp
 - Merge remote-tracking branch 'origin/jdk/8261075-stubroutines-inline' into 
jdk-macos
 - stubRoutines.inline.hpp -> safefetch.hpp
 - Update copyrights
 - Merge remote-tracking branch 'upstream/jdk/master' into 
8261075-stubroutines-inline
 - Merge remote-tracking branch 'upstream/jdk/master' into 
8261075-stubroutines-inline
 - Extract SafeFetch32/N to stubRoutines.inline.hpp
 - Revert "Extract SafeFetch32/N to stubRoutines.inline.hpp"
   
   This reverts commit b873c25f31dd21349d140b790713cc9ccb5f2dc0.
 - ... and 79 more: https://git.openjdk.java.net/jdk/compare/d7efb4cc...74687c0b

-

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=18
  Stats: 2953 lines in 74 files changed: 2862 ins; 27 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8261670: Add javadoc for the XML processing limits [v3]

[Lance Andersen]

On Fri, 26 Feb 2021 08:04:02 GMT, Joe Wang  wrote:

>> Add the documentation for XML processing limits to module summary. The 
>> limits were previously documented in Java tutorial and guide.
>
> Joe Wang has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   s/NumericFormatException/NumberFormatException, remove default id

Looks good Joe.  Added myself as a reviewer to the CSR as well

-

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2732

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v20]

[Anton Kozlov]

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and 
> windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks 
> JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary 
> adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), 
> required on macOS/AArch64 platform. It's implemented with 
> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a 
> thread, so W^X mode change relates to the java thread state change (for java 
> threads). In most cases, JVM executes in write-only mode, except when calling 
> a generated stub like SafeFetch, which requires a temporary switch to 
> execute-only mode. The same execute-only mode is enabled when a java thread 
> executes in java or native states. This approach of managing W^X mode turned 
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with two additional 
commits since the last revision:

 - Merge pull request #10 from VladimirKempik/pull/2200
   
   Fix build after merge with master
 - Fix build after merge with master

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/74687c0b..241aedee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=18-19

  Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

[Vladimir Kempik]

On Tue, 2 Feb 2021 23:07:08 GMT, Daniel D. Daugherty  wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   support macos_aarch64 in hsdis
>
> src/java.base/macosx/native/libjli/java_md_macosx.m line 210:
> 
>> 208: if (preferredJVM == NULL) {
>> 209: #if defined(__i386__)
>> 210: preferredJVM = "client";
> 
> #if defined(__i386__)
> preferredJVM = "client";
> Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on macOS.

Hello
I thought the openjdk7 supported 32-bit macos at some point in time

-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

[Jim Laskey]

On Mon, 4 Jan 2021 13:54:14 GMT, Jim Laskey  wrote:

>> This PR is to introduce a new random number API for the JDK. The primary API 
>> is found in RandomGenerator and RandomGeneratorFactory. Further description 
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>> 
>> javadoc can be found at 
>> http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>> 
>> old PR:  https://github.com/openjdk/jdk/pull/1273
>
> Stayin' alive

Looking for some final code reviews.

-

PR: https://git.openjdk.java.net/jdk/pull/1292

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

[Rémi Forax]

On Fri, 26 Feb 2021 13:13:19 GMT, Jim Laskey  wrote:

>> Stayin' alive
>
> Looking for some final code reviews.

I still don't like the fact that the factory uses reflection but i don't see 
how to do better

-

PR: https://git.openjdk.java.net/jdk/pull/1292

Inconsistency in Constructor.getGenericParameterTypes()

[Oliver Drotbohm]

Previously sent to the wrong list. Sorry for the double post.

Von: Oliver Drotbohm 
Betreff: Inconsistency in Constructor.getGenericParameterTypes()
Datum: 25. Februar 2021 um 10:03:12 MEZ
An: jdk-...@openjdk.java.net

Hi all,

we've just ran into the following issue: for a non-static, generic inner class 
with a constructor declaring a generic parameter, a call to 
constructor.getGenericParameterTypes() does not return the enclosing class 
parameter type. Is that by intention? If so, what's the reasoning behind that?

Here's a the output of a reproducer (below):

static class StaticGeneric - names: value, string
static class StaticGeneric - parameters: [class java.lang.Object, class 
java.lang.String]
static class StaticGeneric - generic parameters: [T, class java.lang.String]

class NonStaticGeneric - names: this$0, value, String
class NonStaticGeneric - parameters: [class Sample, class java.lang.Object, 
class java.lang.String]
class NonStaticGeneric - generic parameters: [T, class java.lang.String]

class NonStaticNonGeneric - names: this$0, String
class NonStaticNonGeneric - parameters: [class Sample, class java.lang.String]
class NonStaticNonGeneric - generic parameters: [class Sample, class 
java.lang.String]

Note how the constructor of the NonStaticGeneric type exposes three 
parameter names, three parameter types but omits the enclosing class parameter 
in the list of generic parameter types.

Tested on JDK 8 to 15. Same behavior.

Cheers,
Ollie


class Sample {

public static void main(String[] args) {

Constructor first = 
StaticGeneric.class.getDeclaredConstructors()[0];

System.out.println("static class StaticGeneric - names: "
+ 
Arrays.stream(first.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
 ")));
System.out.println("static class StaticGeneric - parameters: 
" + Arrays.toString(first.getParameterTypes()));
System.out.println(
"static class StaticGeneric - generic 
parameters: " + Arrays.toString(first.getGenericParameterTypes()));

System.out.println();

Constructor second = 
NonStaticGeneric.class.getDeclaredConstructors()[0];
System.out.println("class NonStaticGeneric - names: "
+ 
Arrays.stream(second.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
 ")));
System.out.println("class NonStaticGeneric - parameters: " + 
Arrays.toString(second.getParameterTypes()));
System.out
.println(
"class NonStaticGeneric - 
generic parameters: " + Arrays.toString(second.getGenericParameterTypes()));

System.out.println();

Constructor third = 
NonStaticNonGeneric.class.getDeclaredConstructors()[0];
System.out.println("class NonStaticNonGeneric - names: "
+ 
Arrays.stream(third.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
 ")));
System.out.println("class NonStaticNonGeneric - parameters: " + 
Arrays.toString(third.getParameterTypes()));
System.out
.println(
"class NonStaticNonGeneric - 
generic parameters: " + Arrays.toString(third.getGenericParameterTypes()));
}

static class StaticGeneric {
StaticGeneric(T value, String string) {}
}

class NonStaticGeneric {
NonStaticGeneric(T value, String String) {}
}

class NonStaticNonGeneric {
NonStaticNonGeneric(String String) {}
}
}

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4]

[Vladimir Ivanov]

On Fri, 26 Feb 2021 02:38:00 GMT, Jie Fu  wrote:

>> Hi all,
>> 
>> Vector API fails to work when:
>>  - case 1: MaxVectorSize is set to <=8, or
>>  - case 2: C2 is disabled
>> 
>> The reason is that {max/preferred} VectorShape initialization fails in both 
>> cases.
>> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns 
>> unreasonable values (0 for case 1 and -1 for case 2).
>> 
>> Vector API should not depend on C2 to run.
>> It should work even there is no JIT compiler since it's a Java-level api.
>> So let's fix it.
>> 
>> Testing:
>>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] 
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364
>
> Jie Fu has updated the pull request incrementally with one additional commit 
> since the last revision:
> 
>   Remove -XX:TieredStopAtLevel=3

IMO the fix should be in 
`src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java`.

JVM does the right job when it signals vector support is absent (by returning 
`-1`).

`jdk.incubator.vector` implementation should take that into account and choose 
a preferred shape for pure Java execution mode.

-

Changes requested by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2722

RFR: 8260869: Test java/foreign/TestHandshake.java fails intermittently

[Maurizio Cimadamore]

This simple fix reduces the amount of concurrency on the foreign memory 
TestHandshake test. As this test spins a new accessor thread for each available 
processors, on machines which feature an high number of available processors 
(because of multi-threading), and which are slower in forking new threads (e.g. 
Windows), the test can sometimes timeout.

The sensible step, for now, is to introduce an hard limit on the number of 
concurrent accessor threads being created. I've looked at the test logs quite 
in depth, and there's nothing suggesting that something else is amiss - the 
number of concurrent threads just seem to be too high in some instances.

-

Commit messages:
 - Reduce concurrency in handshake test

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

PR: https://git.openjdk.java.net/jdk/pull/2748

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

[daniel . daugherty]

On 2/26/21 7:55 AM, Vladimir Kempik wrote:

On Tue, 2 Feb 2021 23:07:08 GMT, Daniel D. Daugherty  wrote:


Anton Kozlov has updated the pull request incrementally with one additional 
commit since the last revision:

   support macos_aarch64 in hsdis

src/java.base/macosx/native/libjli/java_md_macosx.m line 210:


208: if (preferredJVM == NULL) {
209: #if defined(__i386__)
210: preferredJVM = "client";

#if defined(__i386__)
 preferredJVM = "client";
Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on macOS.

Hello
I thought the openjdk7 supported 32-bit macos at some point in time


The macOS porting project supported 32-bit macOS, but when the code
was integrated into OpenJDK7 I don't believe that 32-bit macOS was
supported. I could be wrong... it was quite a while ago...

Dan




-

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]

[erik . joelsson]

On 2021-02-26 06:37, daniel.daughe...@oracle.com wrote:

On 2/26/21 7:55 AM, Vladimir Kempik wrote:
On Tue, 2 Feb 2021 23:07:08 GMT, Daniel D. Daugherty 
 wrote:


Anton Kozlov has updated the pull request incrementally with one 
additional commit since the last revision:


   support macos_aarch64 in hsdis

src/java.base/macosx/native/libjli/java_md_macosx.m line 210:


208: if (preferredJVM == NULL) {
209: #if defined(__i386__)
210: preferredJVM = "client";

#if defined(__i386__)
 preferredJVM = "client";
Not your bug, but Oracle/OpenJDK never supported 32-bit __i386__ on 
macOS.

Hello
I thought the openjdk7 supported 32-bit macos at some point in time


The macOS porting project supported 32-bit macOS, but when the code
was integrated into OpenJDK7 I don't believe that 32-bit macOS was
supported. I could be wrong... it was quite a while ago...

AFAIK, OpenJDK never supported 32bit macos, but there are certainly 
leftovers here and there indicating that the original source did at some 
point. In the build system we cleaned that up a long time ago.


/Erik

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4]

[Jie Fu]

On Fri, 26 Feb 2021 13:55:15 GMT, Vladimir Ivanov  wrote:

> IMO the fix should be in 
> `src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java`.
> 
> JVM does the right job when it signals vector support is absent (by returning 
> `-1`).
> 
> `jdk.incubator.vector` implementation should take that into account and 
> choose a preferred shape for pure Java execution mode.

Hi @iwanowww ,

Thanks for your review.

>From the view of C2 compiler, you are right.

But the Java programmer may be confused if we got something like 
DoubleVector.SPECIES_PREFERRED.length() > 
VectorSupport.getMaxLaneCount(double.class).
I'd like to keep DoubleVector.SPECIES_PREFERRED.length() <= 
VectorSupport.getMaxLaneCount(double.class) for Java programmers since the 
VectorSupport_GetMaxLaneCount is used to implement a Java API.

What do you think?
Thanks.

-

PR: https://git.openjdk.java.net/jdk/pull/2722

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4]

[Vladimir Ivanov]

On Fri, 26 Feb 2021 15:37:08 GMT, Jie Fu  wrote:

> I'd like to keep DoubleVector.SPECIES_PREFERRED.length() <= 
> VectorSupport.getMaxLaneCount(double.class) for Java programmers since the 
> VectorSupport_GetMaxLaneCount is used to implement a Java API.

It doesn't make much sense to me. `VectorSupport` is an internal API for 
`jdk.incubator.vector` to consume.
It's `jdk.incubator.vector` job to interpret the result and adapt accordingly.

-

PR: https://git.openjdk.java.net/jdk/pull/2722

Re: RFR: 8261670: Add javadoc for the XML processing limits [v3]

[Naoto Sato]

On Fri, 26 Feb 2021 08:04:02 GMT, Joe Wang  wrote:

>> Add the documentation for XML processing limits to module summary. The 
>> limits were previously documented in Java tutorial and guide.
>
> Joe Wang has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   s/NumericFormatException/NumberFormatException, remove default id

Looks good. Thanks for making the changes.

-

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2732

RFR: 8173970: jar tool should have a way to extract to a directory

[Jaikiran Pai]

Can I please get a review for this patch which proposes to implement the 
enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?

The commit in this PR introduces the `-o` and `--output-dir` option to the 
`jar` command. The option takes a path to a destination directory as a value 
and extracts the contents of the jar into that directory. This is an optional 
option and the changes in the commit continue to maintain backward 
compatibility where the jar is extracted into current directory, if no `-o` or 
`--output-dir` option has been specified.

As far as I know, there hasn't been any discussion on what the name of this new 
option should be. I was initially thinking of using `-d` but that is currently 
used by the `jar` command for a different purpose. So I decided to use `-o` and 
`--output-dir`. This is of course open for change depending on any suggestions 
in this PR.

The commit in this PR also updates the `jar.properties` file which contains the 
English version of the jar command's `--help` output. However, no changes have 
been done to the internationalization files corresponding to this one (for 
example: `jar_de.properties`), because I don't know what process needs to be 
followed to have those files updated (if at all they need to be updated).

The commit also includes a jtreg testcase which verifies the usage of this new 
option.

-

Commit messages:
 - 8173970: jar tool should have a way to extract to a directory

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

PR: https://git.openjdk.java.net/jdk/pull/2752

RFR: JDK-8262471: Fix coding style in src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java

[Christoph Göttschkes]

Please review this small patch which fixes the coding style of 
CharacterDataPrivateUse.java

-

Commit messages:
 - Fixes coding style.

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

PR: https://git.openjdk.java.net/jdk/pull/2754

Re: RFR: 8260869: Test java/foreign/TestHandshake.java fails intermittently

[Paul Sandoz]

On Fri, 26 Feb 2021 14:25:09 GMT, Maurizio Cimadamore  
wrote:

> This simple fix reduces the amount of concurrency on the foreign memory 
> TestHandshake test. As this test spins a new accessor thread for each 
> available processors, on machines which feature an high number of available 
> processors (because of multi-threading), and which are slower in forking new 
> threads (e.g. Windows), the test can sometimes timeout.
> 
> The sensible step, for now, is to introduce an hard limit on the number of 
> concurrent accessor threads being created. I've looked at the test logs quite 
> in depth, and there's nothing suggesting that something else is amiss - the 
> number of concurrent threads just seem to be too high in some instances.

test/jdk/java/foreign/TestHandshake.java line 60:

> 58: 
> 59: static final int NUM_ACCESSORS = Math.max(10, 
> Runtime.getRuntime().availableProcessors());
> 60: 

`min` rather than `max` so as to clamp at a maximum of 10 accessors?

-

PR: https://git.openjdk.java.net/jdk/pull/2748

Re: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]

[Anton Kozlov]

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and 
> windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks 
> JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary 
> adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), 
> required on macOS/AArch64 platform. It's implemented with 
> pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a 
> thread, so W^X mode change relates to the java thread state change (for java 
> threads). In most cases, JVM executes in write-only mode, except when calling 
> a generated stub like SafeFetch, which requires a temporary switch to 
> execute-only mode. The same execute-only mode is enabled when a java thread 
> executes in java or native states. This approach of managing W^X mode turned 
> out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with two additional 
commits since the last revision:

 - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
 - Minor fixes

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/241aedee..663cb4a1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=19-20

  Stats: 85 lines in 5 files changed: 0 ins; 80 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

Re: RFR: 8173970: jar tool should have a way to extract to a directory

[Lance Andersen]

Hi Jaikiran,

Thank you for  the proposed patch.

Assuming there is consensus to add support for this enhancement, I think we 
need to discuss what is the correct option.

The jar tool borrows -C from tar for creating/updating a jar and the -C option 
is also a valid option when extracting files from a tar file.

Perhaps keeping symmetry with tar and extend support for -C when extracting a 
jar file would be a better way forward.   Let’s give time for additional input.

I believe this would also warrant a CSR to be created as well as updates to the 
jar man page.

Best
Lance

p.s. I think it would be useful in the future to start the discussion on 
core-libs-dev prior to creating a PR (or leave it as a draft PR) for a feature 
request.

On Feb 26, 2021, at 12:08 PM, Jaikiran Pai 
mailto:j...@openjdk.java.net>> wrote:

Can I please get a review for this patch which proposes to implement the 
enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?

The commit in this PR introduces the `-o` and `--output-dir` option to the 
`jar` command. The option takes a path to a destination directory as a value 
and extracts the contents of the jar into that directory. This is an optional 
option and the changes in the commit continue to maintain backward 
compatibility where the jar is extracted into current directory, if no `-o` or 
`--output-dir` option has been specified.

As far as I know, there hasn't been any discussion on what the name of this new 
option should be. I was initially thinking of using `-d` but that is currently 
used by the `jar` command for a different purpose. So I decided to use `-o` and 
`--output-dir`. This is of course open for change depending on any suggestions 
in this PR.

The commit in this PR also updates the `jar.properties` file which contains the 
English version of the jar command's `--help` output. However, no changes have 
been done to the internationalization files corresponding to this one (for 
example: `jar_de.properties`), because I don't know what process needs to be 
followed to have those files updated (if at all they need to be updated).

The commit also includes a jtreg testcase which verifies the usage of this new 
option.

-

Commit messages:
- 8173970: jar tool should have a way to extract to a directory

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

PR: https://git.openjdk.java.net/jdk/pull/2752

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC@home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v5]

[Ian Graves]

> Modify the `unmodifiable*` methods in `java.util.Collections` to be 
> idempotent. That is, when given an immutable collection from 
> `java.util.ImmutableCollections` or `java.util.Collections`, these methods 
> will return the reference instead of creating a new immutable collection that 
> wraps the existing one.

Ian Graves has updated the pull request incrementally with one additional 
commit since the last revision:

  Test refactoring. Adding implNote to modified methods

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2596/files
  - new: https://git.openjdk.java.net/jdk/pull/2596/files/ebdd0f85..8109e158

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=03-04

  Stats: 185 lines in 2 files changed: 12 ins; 142 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2596.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2596/head:pull/2596

PR: https://git.openjdk.java.net/jdk/pull/2596

Re: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v4]

[Ian Graves]

On Wed, 24 Feb 2021 01:58:48 GMT, Stuart Marks  wrote:

>>> Is there any behavior change here that merits a CSR review?
>> 
>> Yes. See my comments in the bug report:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-6323374?focusedCommentId=14296330&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14296330
>> 
>> There is not only the issue of the identity of the object returned, but the 
>> change is also observable in the serialized form. Most people would consider 
>> the change (less nesting) to be an improvement, but the change is 
>> observable, and as we know any observable behavior can become depended upon 
>> by applications.
>
> Code changes all look good. I'm thinking that we should add `@implNote` 
> clauses to all the docs of the affected methods, saying something like "This 
> method may return its argument if it is already unmodifiable." Usually it's 
> reasonable to leave these kinds of behaviors unspecified (and we do so 
> elsewhere) but since this is a change in long-standing behavior, it seems 
> reasonable to highlight it explicitly. I don't think we want to specify it 
> though, because of the issue with ImmutableCollections (as discussed 
> previously) and possible future tuning of behavior regarding the various Set 
> and Map subinterfaces. (For example, C.unmodifiableSet(arg) could return arg 
> if it's an UnmodifiableNavigableSet.)
> 
> The test seems to have a lot of uncomfortable dependencies, both explicit and 
> implicit, on the various ImmutableCollection and UnmodifiableX implementation 
> classes. Would it be sufficient to test various instances for reference 
> equality and inequality instead? For example, something like
> 
> var list0 = List.of();
> var list1 = Collections.unmodifiableList(list0);
> var list2 = Collections.unmodifiableList(list1);
> assertNotSame(list0, list1);
> assertSame(list1, list2);
> 
> This would avoid having to write test cases that cover various internal 
> classes. The ImmutableCollections classes have been reorganized in the past, 
> and while we don't have any plans to do so again at the moment, there is 
> always the possibility of it happening again.
> 
> One could write out all the different cases "by hand" but there are rather a 
> lot of them. It might be fruitful to extract the "wrap once, wrap again, 
> assertNotSame, assertSame" logic into a generic test and drive it somehow 
> with a data provider that provides the base instance and a wrapper function.

Per @stuart-marks I rewrote the tests using some of his suggestions, which 
substantially reduced dependencies and test size.

-

PR: https://git.openjdk.java.net/jdk/pull/2596

Re: RFR: 8261670: Add javadoc for the XML processing limits [v3]

[Iris Clark]

On Fri, 26 Feb 2021 08:04:02 GMT, Joe Wang  wrote:

>> Add the documentation for XML processing limits to module summary. The 
>> limits were previously documented in Java tutorial and guide.
>
> Joe Wang has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   s/NumericFormatException/NumberFormatException, remove default id

Looks good.  I'm glad to see useful information from the outdated 
guides/tutorial being integrated into this documentation.

-

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2732

Re: Inconsistency in Constructor.getGenericParameterTypes()

[Joe Darcy]

Hello Oliver,

This is long-standing if surprising and under-documented behavior.

The getGenericFoo methods, when generic type information is present, 
give a source-level view of the element. At a source level, the implicit 
outer this parameter is not present and thus omitted by 
constructor.getGenericParameterTypes for the constructor in question.


HTH,

-Joe

On 2/26/2021 5:41 AM, Oliver Drotbohm wrote:

Previously sent to the wrong list. Sorry for the double post.

Von: Oliver Drotbohm 
Betreff: Inconsistency in Constructor.getGenericParameterTypes()
Datum: 25. Februar 2021 um 10:03:12 MEZ
An: jdk-...@openjdk.java.net

Hi all,

we've just ran into the following issue: for a non-static, generic inner class 
with a constructor declaring a generic parameter, a call to 
constructor.getGenericParameterTypes() does not return the enclosing class 
parameter type. Is that by intention? If so, what's the reasoning behind that?

Here's a the output of a reproducer (below):

static class StaticGeneric - names: value, string
static class StaticGeneric - parameters: [class java.lang.Object, class 
java.lang.String]
static class StaticGeneric - generic parameters: [T, class java.lang.String]

class NonStaticGeneric - names: this$0, value, String
class NonStaticGeneric - parameters: [class Sample, class java.lang.Object, 
class java.lang.String]
class NonStaticGeneric - generic parameters: [T, class java.lang.String]

class NonStaticNonGeneric - names: this$0, String
class NonStaticNonGeneric - parameters: [class Sample, class java.lang.String]
class NonStaticNonGeneric - generic parameters: [class Sample, class 
java.lang.String]

Note how the constructor of the NonStaticGeneric type exposes three 
parameter names, three parameter types but omits the enclosing class parameter in the 
list of generic parameter types.

Tested on JDK 8 to 15. Same behavior.

Cheers,
Ollie


class Sample {

public static void main(String[] args) {

Constructor first = 
StaticGeneric.class.getDeclaredConstructors()[0];

System.out.println("static class StaticGeneric - names: "
+ 
Arrays.stream(first.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
 ")));
System.out.println("static class StaticGeneric - parameters: 
" + Arrays.toString(first.getParameterTypes()));
System.out.println(
"static class StaticGeneric - generic parameters: 
" + Arrays.toString(first.getGenericParameterTypes()));

System.out.println();

Constructor second = 
NonStaticGeneric.class.getDeclaredConstructors()[0];
System.out.println("class NonStaticGeneric - names: "
+ 
Arrays.stream(second.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
 ")));
System.out.println("class NonStaticGeneric - parameters: " + 
Arrays.toString(second.getParameterTypes()));
System.out
.println(
"class NonStaticGeneric - generic 
parameters: " + Arrays.toString(second.getGenericParameterTypes()));

System.out.println();

Constructor third = 
NonStaticNonGeneric.class.getDeclaredConstructors()[0];
System.out.println("class NonStaticNonGeneric - names: "
+ 
Arrays.stream(third.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
 ")));
System.out.println("class NonStaticNonGeneric - parameters: " + 
Arrays.toString(third.getParameterTypes()));
System.out
.println(
"class NonStaticNonGeneric - generic 
parameters: " + Arrays.toString(third.getGenericParameterTypes()));
}

static class StaticGeneric {
StaticGeneric(T value, String string) {}
}

class NonStaticGeneric {
NonStaticGeneric(T value, String String) {}
}

class NonStaticNonGeneric {
NonStaticNonGeneric(String String) {}
}
}

Re: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and synchronized* [v5]

[Stuart Marks]

On Fri, 26 Feb 2021 20:15:19 GMT, Ian Graves  wrote:

>> Modify the `unmodifiable*` methods in `java.util.Collections` to be 
>> idempotent. That is, when given an immutable collection from 
>> `java.util.ImmutableCollections` or `java.util.Collections`, these methods 
>> will return the reference instead of creating a new immutable collection 
>> that wraps the existing one.
>
> Ian Graves has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Test refactoring. Adding implNote to modified methods

The `@implNote` additions are good, and the test rewrite looks good too.

-

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2596

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v25]

[Roger Riggs]

On Tue, 23 Feb 2021 16:47:59 GMT, Jim Laskey  wrote:

>> This PR is to introduce a new random number API for the JDK. The primary API 
>> is found in RandomGenerator and RandomGeneratorFactory. Further description 
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>> 
>> javadoc can be found at 
>> http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>> 
>> old PR:  https://github.com/openjdk/jdk/pull/1273
>
> Jim Laskey has updated the pull request with a new target base due to a merge 
> or a rebase. The pull request now contains 57 commits:
> 
>  - Merge branch 'master' into 8248862
>  - Adjust ThreadLocalRandom javadoc inheritence
>  - L32X64StarStarRandom -> L32X64MixRandom
>  - Various corrects
>  - Revised javadoc per CSR reviews
>  - Remove tabs from random/package-info.java
>  - Correct copyright notice.
>  - Merge branch 'master' into 8248862
>  - Update tests for RandomGeneratorFactory.all()
>  - Merge branch 'master' into 8248862
>  - ... and 47 more: 
> https://git.openjdk.java.net/jdk/compare/0257caad...b9094279

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 
232:

> 230: Provider provider = fm.get(name);
> 231: if (!isSubclass(category, provider)) {
> 232: throw new IllegalArgumentException(name + " is an unknown 
> random number generator");

The message is a bit vague. How about:

"The random number generator does not support the category"

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 
240:

> 238:  * Returns a {@link RandomGenerator} that utilizes the {@code name}
> 239:  * algorithm.
> 240:  *

In javadoc, this seems like is should read as: "utilizes the named algorithm".
The use of the parameter name is unnecessary in this case because it is obvious 
and readability suffers as is.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 1313:

> 1311:  * furthermore can easily jump to an arbitrarily specified 
> distant
> 1312:  * point in the state cycle.
> 1313:  *

The similarity of the first sentence of each of the Jumpable, Leapable, and 
arbitrarlyJumpable interface is so similar as to obscure the differences. You 
have to read 25 words in to be able to find the description that makes them 
different. The italics help but should include the whole of the phrase that 
distinguishes them.
Alternatively, move the phrase to the beginning of the sentence or drop the 
redundant phrasing.
"provide a common protocol of objects that generate pseudorandom sequences of 
numbers of Boolean values", etc.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 
55:

> 53:  *
> 54:  * A specific {@link RandomGeneratorFactory} can be located by using the
> 55:  * {@link RandomGenerator#factoryOf(String)} method, where the argument 
> string

Broken link: the method is in this class.  should be just "#factoryOf".

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 
600:

> 598: try {
> 599: ensureConstructors();
> 600: return ctorBytes.newInstance((Object)seed);

IntelliJ warns that the cast to (Object) is redundant.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 
29:

> 27: 
> 28: import java.lang.reflect.Constructor;
> 29: import java.lang.reflect.Method;

Used import.

-

PR: https://git.openjdk.java.net/jdk/pull/1292

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

[Roger Riggs]

On Wed, 25 Nov 2020 16:22:32 GMT, Jim Laskey  wrote:

>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java 
>> line 106:
>> 
>>> 104:  * Map of provider classes.
>>> 105:  */
>>> 106: private static volatile Map>> RandomGenerator>> factoryMap;
>> 
>> should be FACTORY_MAP given that it's a static field
>
> will fall out of using  class holder idiom

IntelliJ warns that this volatile field is unused. It has been replaced by the 
method getFactoryMap().

-

PR: https://git.openjdk.java.net/jdk/pull/1292

Re: Inconsistency in Constructor.getGenericParameterTypes()

[Oliver Drotbohm]

Hi Joe,

thanks for the explanation. We switched to rather iterating over 
….getParameters() and take it from there. Do you think it makes sense to leave 
a note about this in the Javadoc?

Cheers,
Ollie

> Am 26.02.2021 um 22:38 schrieb Joe Darcy :
> 
> Hello Oliver,
> 
> This is long-standing if surprising and under-documented behavior.
> 
> The getGenericFoo methods, when generic type information is present, give a 
> source-level view of the element. At a source level, the implicit outer this 
> parameter is not present and thus omitted by 
> constructor.getGenericParameterTypes for the constructor in question.
> 
> HTH,
> 
> -Joe
> 
> On 2/26/2021 5:41 AM, Oliver Drotbohm wrote:
>> Previously sent to the wrong list. Sorry for the double post.
>> 
>> Von: Oliver Drotbohm 
>> Betreff: Inconsistency in Constructor.getGenericParameterTypes()
>> Datum: 25. Februar 2021 um 10:03:12 MEZ
>> An: jdk-...@openjdk.java.net
>> 
>> Hi all,
>> 
>> we've just ran into the following issue: for a non-static, generic inner 
>> class with a constructor declaring a generic parameter, a call to 
>> constructor.getGenericParameterTypes() does not return the enclosing class 
>> parameter type. Is that by intention? If so, what's the reasoning behind 
>> that?
>> 
>> Here's a the output of a reproducer (below):
>> 
>> static class StaticGeneric - names: value, string
>> static class StaticGeneric - parameters: [class java.lang.Object, class 
>> java.lang.String]
>> static class StaticGeneric - generic parameters: [T, class 
>> java.lang.String]
>> 
>> class NonStaticGeneric - names: this$0, value, String
>> class NonStaticGeneric - parameters: [class Sample, class 
>> java.lang.Object, class java.lang.String]
>> class NonStaticGeneric - generic parameters: [T, class java.lang.String]
>> 
>> class NonStaticNonGeneric - names: this$0, String
>> class NonStaticNonGeneric - parameters: [class Sample, class 
>> java.lang.String]
>> class NonStaticNonGeneric - generic parameters: [class Sample, class 
>> java.lang.String]
>> 
>> Note how the constructor of the NonStaticGeneric type exposes three 
>> parameter names, three parameter types but omits the enclosing class 
>> parameter in the list of generic parameter types.
>> 
>> Tested on JDK 8 to 15. Same behavior.
>> 
>> Cheers,
>> Ollie
>> 
>> 
>> class Sample {
>> 
>>  public static void main(String[] args) {
>> 
>>  Constructor first = 
>> StaticGeneric.class.getDeclaredConstructors()[0];
>> 
>>  System.out.println("static class StaticGeneric - names: "
>>  + 
>> Arrays.stream(first.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
>>  ")));
>>  System.out.println("static class StaticGeneric - parameters: 
>> " + Arrays.toString(first.getParameterTypes()));
>>  System.out.println(
>>  "static class StaticGeneric - generic 
>> parameters: " + Arrays.toString(first.getGenericParameterTypes()));
>> 
>>  System.out.println();
>> 
>>  Constructor second = 
>> NonStaticGeneric.class.getDeclaredConstructors()[0];
>>  System.out.println("class NonStaticGeneric - names: "
>>  + 
>> Arrays.stream(second.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
>>  ")));
>>  System.out.println("class NonStaticGeneric - parameters: " + 
>> Arrays.toString(second.getParameterTypes()));
>>  System.out
>>  .println(
>>  "class NonStaticGeneric - 
>> generic parameters: " + Arrays.toString(second.getGenericParameterTypes()));
>> 
>>  System.out.println();
>> 
>>  Constructor third = 
>> NonStaticNonGeneric.class.getDeclaredConstructors()[0];
>>  System.out.println("class NonStaticNonGeneric - names: "
>>  + 
>> Arrays.stream(third.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
>>  ")));
>>  System.out.println("class NonStaticNonGeneric - parameters: " + 
>> Arrays.toString(third.getParameterTypes()));
>>  System.out
>>  .println(
>>  "class NonStaticNonGeneric - 
>> generic parameters: " + Arrays.toString(third.getGenericParameterTypes()));
>>  }
>> 
>>  static class StaticGeneric {
>>  StaticGeneric(T value, String string) {}
>>  }
>> 
>>  class NonStaticGeneric {
>>  NonStaticGeneric(T value, String String) {}
>>  }
>> 
>>  class NonStaticNonGeneric {
>>  NonStaticNonGeneric(String String) {}
>>  }
>> }
>> 

Re: RFR: 8173970: jar tool should have a way to extract to a directory

[Jaikiran Pai]

Hello Lance,

On 27/02/21 1:17 am, Lance Andersen wrote:



p.s. I think it would be useful in the future to start the discussion 
on core-libs-dev prior to creating a PR (or leave it as a draft PR) 
for a feature request.


Thank you for that input, I'll keep that in mind for any similar work in 
future.



-Jaikiran

Re: RFR: 8173970: jar tool should have a way to extract to a directory

[Jaikiran Pai]

On 27/02/21 1:17 am, Lance Andersen wrote:


I believe this would also warrant a CSR to be created as well as 
updates to the jar man page.



I haven't created a CSR before, so I will need some guidance on that 
part. Is it usually created after all the implementation details have 
been decided upon or should it be created now?


-Jaikiran

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v5]

[Jie Fu]

> Hi all,
> 
> Vector API fails to work when:
>  - case 1: MaxVectorSize is set to <=8, or
>  - case 2: C2 is disabled
> 
> The reason is that {max/preferred} VectorShape initialization fails in both 
> cases.
> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns 
> unreasonable values (0 for case 1 and -1 for case 2).
> 
> Vector API should not depend on C2 to run.
> It should work even there is no JIT compiler since it's a Java-level api.
> So let's fix it.
> 
> Testing:
>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

Jie Fu has updated the pull request with a new target base due to a merge or a 
rebase. The incremental webrev excludes the unrelated changes brought in by the 
merge/rebase. The pull request contains seven additional commits since the last 
revision:

 - Fix in jdk/incubator/vector/VectorShape.java
 - Merge branch 'master' into JDK-8262096
 - Revert changes
 - Remove -XX:TieredStopAtLevel=3
 - Update the jtreg test
 - The numerator should be 8 (byte)
 - 8262096: Vector API fails to work due to VectorShape initialization exception

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2722/files
  - new: https://git.openjdk.java.net/jdk/pull/2722/files/bbe6150c..b67b232d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=03-04

  Stats: 7047 lines in 380 files changed: 3707 ins; 1675 del; 1665 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2722.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722

PR: https://git.openjdk.java.net/jdk/pull/2722

Re: RFR: 8262096: Vector API fails to work due to VectorShape initialization exception [v4]

[Jie Fu]

On Fri, 26 Feb 2021 15:48:18 GMT, Vladimir Ivanov  wrote:

> > I'd like to keep DoubleVector.SPECIES_PREFERRED.length() <= 
> > VectorSupport.getMaxLaneCount(double.class) for Java programmers since the 
> > VectorSupport_GetMaxLaneCount is used to implement a Java API.
> 
> It doesn't make much sense to me. `VectorSupport` is an internal API for 
> `jdk.incubator.vector` to consume.
> It's `jdk.incubator.vector` job to interpret the result and adapt accordingly.

Okay, I'm fine to fix it in jdk/incubator/vector/VectorShape.java if we don't 
keep something like that.

For the updated fix, the {max/preferred} shape will be initialized as 
shape-64-bit if hotspot doesn't support vectorization.

Testing:
  - jdk/incubator/vector with MaxVectorSize=default/8/4 on Linux/x64 
  - jdk/incubator/vector without C2 on Linux/x64

Any comments?
Thanks.

-

PR: https://git.openjdk.java.net/jdk/pull/2722