Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml

[Alexey Semenyuk]

On Mon, 13 Jun 2022 17:01:48 GMT, Alexander Matveev  
wrote:

> - Error will be thrown if app image is generated with another JDK version or 
> has malformed .jpackage.xml.
>  - Re-fixed as Alexey suggested in https://github.com/openjdk/jdk/pull/9098.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties
 line 79:

> 77: warning.no.jdk.modules.found=Warnung: Keine JDK-Module gefunden
> 78: 
> 79: error.foreign-app-image=Error: app-image dir ({0}) not generated by 
> jpackage. Missing .jpackage.xml.

This error message will be misleading in case app image was generated by 
jpackage and adjusted after.
I'd put it as "Missing .jpackage.xml file in app-image dir ({0})."

-

PR: https://git.openjdk.org/jdk19/pull/9

Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml

[Alexey Semenyuk]

On Mon, 13 Jun 2022 17:01:48 GMT, Alexander Matveev  
wrote:

> - Error will be thrown if app image is generated with another JDK version or 
> has malformed .jpackage.xml.
>  - Re-fixed as Alexey suggested in https://github.com/openjdk/jdk/pull/9098.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 68:

> 66: private final List addLauncherInfos;
> 67: private final String signedStr;
> 68: private final String appStoreStr;

What is the idea of this change?

-

PR: https://git.openjdk.org/jdk19/pull/9

Re: RFR: 8288425: Footprint regression due MH creation when initializing StringConcatFactory

[Mandy Chung]

On Tue, 14 Jun 2022 15:16:27 GMT, Claes Redestad  wrote:

> Avoid doing MH creation when initializing `StringConcatFactory` by lazily 
> initializing to a `@Stable` field instead.

Marked as reviewed by mchung (Reviewer).

-

PR: https://git.openjdk.org/jdk/pull/9154

Re: RFR: 8287186: JDK modules participating in preview [v2]

[Paul Sandoz]

On Wed, 8 Jun 2022 22:07:38 GMT, liach  wrote:

>> Paul Sandoz has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Let java.management participate in preview features.
>
> Just curious, is it still up to incubator modules' discretion to avoid 
> accidental user access to preview content via the modules without enabling 
> preview, like the `PreviewFeatures.ensureEnabled()` in `StructuredTaskScope`?

@liach it depends on the API and its scope. A constructor of 
`StructuredTaskScope` specifies that it implicitly uses a virtual thread 
factory, so it performs a preview runtime check. 

The same check is also performed by `Thread.ofVirtual`, ensuring developers 
cannot reflectively work around 
`--enable-preview` when creating virtual threads. This approach is feasible 
since the API surface is so small.

-

PR: https://git.openjdk.org/jdk/pull/9087

RFR: 8288414: Long::compress/expand samples are not correct

[Paul Sandoz]

Update the code examples in the api notes of Long::compress/expand. Some 
constants need to be explicitly long values.

-

Commit messages:
 - Correct Long.compress/expand api notes.

Changes: https://git.openjdk.org/jdk19/pull/14/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk19=14=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288414
  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk19/pull/14.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/14/head:pull/14

PR: https://git.openjdk.org/jdk19/pull/14

Re: RFR: 8288414: Long::compress/expand samples are not correct

[Alan Bateman]

On Tue, 14 Jun 2022 16:28:37 GMT, Paul Sandoz  wrote:

> Update the code examples in the api notes of Long::compress/expand. Some 
> constants need to be explicitly long values.

Marked as reviewed by alanb (Reviewer).

-

PR: https://git.openjdk.org/jdk19/pull/14

Re: RFR: 8288425: Footprint regression due MH creation when initializing StringConcatFactory

[Jorn Vernee]

On Tue, 14 Jun 2022 15:16:27 GMT, Claes Redestad  wrote:

> Avoid doing MH creation when initializing `StringConcatFactory` by lazily 
> initializing to a `@Stable` field instead.

Marked as reviewed by jvernee (Reviewer).

-

PR: https://git.openjdk.org/jdk/pull/9154

Integrated: 8287186: JDK modules participating in preview

[Paul Sandoz]

On Wed, 8 Jun 2022 15:46:24 GMT, Paul Sandoz  wrote:

> Allow JDK modules that use preview features (preview language features or 
> preview API features from dependent modules) to participate without the need 
> to compile with `--enable-preview`.
> 
> It's difficult to enable participation using an annotation due to the nature 
> in which symbols are encountered when processing source as there is no 
> guaranteed order to the processing of certain symbols.
> 
> Instead a JDK module participates if the `java.base` package 
> `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An 
> internal annotation `jdk.internal.javac.ParticipatesInPreview` can be 
> declared on the module. Such a declaration cannot be enforced but does by its 
> use require the `jdk.internal.javac`'s export list to be updated.
> 
> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been 
> updated accordingly, both of which participate in preview APIs (APIs in 
> `java.lang.foreign` and `Thread.ofVirtual`, respectively).

This pull request has now been integrated.

Changeset: fb297705
Author:Paul Sandoz 
URL:   
https://git.openjdk.org/jdk/commit/fb297705f6dc668bea0257efb9c46b90b5eab2e9
Stats: 140 lines in 12 files changed: 65 ins; 57 del; 18 mod

8287186: JDK modules participating in preview

Reviewed-by: alanb, jlahoda

-

PR: https://git.openjdk.org/jdk/pull/9087

Re: [Very fast List/Deque to java.util?]

[Rodion Efremov]

ti 14.6.2022 klo 18.49 Rodion Efremov  kirjoitti:

> Hi community,
>
> > One use case I've had in the past was for a list that is
> always sorted but also allows index based access when displaying a
> window into the list.
>
> I suppose you are talking about an order statistic tree. If that is the
> case, I have one [1].
>
> Best regards,
> rodde
>
> [1] https://github.com/coderodde/OrderStatisticTree
>
>
> ma 13.6.2022 klo 15.00 John Hendrikx  kirjoitti:
>
>> I took a look.
>>
>> I found a few results odd:
>>
>> |com.github.coderodde.util.IndexedLinkedList.addLast in (ms): 8
>> java.util.LinkedList.addLast in (ms): 2 java.util.ArrayList.addLast in
>> (ms): 157 org.apache.commons.collections4.list.TreeList.addLast in (ms):
>> 38|
>>
>> Basically, ArrayList's performance (which should be O(1) in this case)
>> is surprising. Looking at the benchmark, it is calling
>> ArrayList#add(int, E) -- this method is not special cased for adding at
>> the end of the list (it will do a range check and call System#arrayCopy
>> in all cases).
>>
>> |com.github.coderodde.util.IndexedLinkedList.stream() in (ms): 1
>> java.util.LinkedList.stream() in (ms): 20 java.util.ArrayList.stream()
>> in (ms): 16 org.apache.commons.collections4.list.TreeList.stream() in
>> (ms): 15|
>>
>> This test isn't only measuring streaming (iteration?) but also
>> re-inserting all elements back into a List
>> (collect(Collectors.toList()). What I find odd is that the
>> IndexedLinkedList would perform much better here than ArrayList, given
>> that the time is probably dominated by the final collect, and not the
>> iteration itself.  Is ArrayList#stream poorly optimized or is something
>> else going on?
>>
>> A pure iteration test would be interesting to see.
>>
>> I also ran the benchmark on my machine. The benchmark on Github doesn't
>> mention with what parameters it is run, and so when I run it I get quite
>> different results. The committed version of the benchmark seems to use
>> collections with a max size of 20 elements. The total time when I run
>> the benchmark favors TreeList more than any other:
>>
>> --- Total time elapsed ---
>> com.github.coderodde.util.IndexedLinkedList in (ms): 207
>> java.util.LinkedList in (ms): 4248
>> java.util.ArrayList in (ms): 1799
>> org.apache.commons.collections4.list.TreeList in (ms): 159
>>
>> That said, I think there might be a place for a new list implementation
>> in the JDK.  One use case I've had in the past was for a list that is
>> always sorted but also allows index based access when displaying a
>> window into the list. A TreeMap satisfies the sorting criteria but
>> doesn't offer index access, while a plain ArrayList doesn't lend itself
>> well for doing sorted inserts/removals (locating the correct location is
>> trivial enough, but the actual insert or removal results in a
>> potentially large copy).  Apache's TreeList is fairly good at this use
>> case.
>>
>> --John
>>
>>
>> On 13/06/2022 09:56, Rodion Efremov wrote:
>> > Hello,
>> >
>> > I have this List/Deque implementation [1] that (in a versatile
>> benchmark)
>> > runs much faster than ArrayList/LinkedList. Under mild assumptions, it
>> > accesses an element in O(sqrt(N)) time.
>> >
>> > Now, if all we want to do is to add at the tail and read via get(int
>> > index), you are better of using java.util.ArrayList. If you wish to
>> iterate
>> > a list removing some elements, the way to go is to use
>> java.util.LinkedList.
>> >
>> >   However,, if you deal with larger lists via many different operations
>> > (addFirst/addLast/add(int, E)/get(int)/remove(int)/ettc. my
>> > IndexedLinkedLiist will outperform both of them gracefully.
>> >
>> > So, what do you think? Does it deserve to become a class candidate for
>> > java.util?
>> >
>> > [1]https://github.com/coderodde/IndexedLinkedList
>>
>

RFR: 8288425: Footprint regression due MH creation when initializing StringConcatFactory

[Claes Redestad]

Avoid doing MH creation when initializing `StringConcatFactory` by lazily 
initializing to a `@Stable` field instead.

-

Commit messages:
 - 8288425: Footprint regression due MH creation when initializing 
StringConcatFactory

Changes: https://git.openjdk.org/jdk/pull/9154/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9154=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288425
  Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9154.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9154/head:pull/9154

PR: https://git.openjdk.org/jdk/pull/9154

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v25]

[Roger Riggs]

On Tue, 14 Jun 2022 02:32:54 GMT, Joe Darcy  wrote:

>> This is an early review of changes to better model JVM access flags, that is 
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but 
>> distinct. There are concepts that overlap in the two domains (public, 
>> private, etc.), others that only have a language-level modifier (sealed), 
>> and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these 
>> subtleties. For example, the bit positions used by access flags on different 
>> kinds of elements overlap (such as "volatile" for fields and "bridge" for 
>> methods. Just having a raw integer does not provide sufficient context to 
>> decode the corresponding language-level string. Methods like 
>> Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like 
>> Valhalla, addressing the existent modeling deficiency now ahead of time is 
>> reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. 
>> It is missing implementations to map from, say, method modifiers to access 
>> flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in 
>> once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Respond to review feedback.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 64:

> 62:  * arity (varargs)} method.
> 63:  *
> 64:  * The access flag constants are ordered by non-decreasing mask

This paragraph seems more like an @implNote, describing the ordering of the 
source.

-

PR: https://git.openjdk.org/jdk/pull/7445

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v25]

[Roger Riggs]

On Tue, 14 Jun 2022 02:32:54 GMT, Joe Darcy  wrote:

>> This is an early review of changes to better model JVM access flags, that is 
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but 
>> distinct. There are concepts that overlap in the two domains (public, 
>> private, etc.), others that only have a language-level modifier (sealed), 
>> and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these 
>> subtleties. For example, the bit positions used by access flags on different 
>> kinds of elements overlap (such as "volatile" for fields and "bridge" for 
>> methods. Just having a raw integer does not provide sufficient context to 
>> decode the corresponding language-level string. Methods like 
>> Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like 
>> Valhalla, addressing the existent modeling deficiency now ahead of time is 
>> reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. 
>> It is missing implementations to map from, say, method modifiers to access 
>> flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in 
>> once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Respond to review feedback.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 104:

> 102:  */
> 103: PROTECTED(Modifier.PROTECTED, true,
> 104:   Set.of(Location.FIELD, Location.METHOD, 
> Location.INNER_CLASS)),

In both space and startup time, creating separate sets for the same set of 
Locations is inefficient.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 213:

> 211:  * {@value "0x%04x" Modifier#STRICT}.
> 212:  */
> 213: STRICT(Modifier.STRICT, true, Set.of(Location.METHOD)),

ACC_STRICT is defined for class files and appears in the Class.getModifiers() 
before class file version 46. 
Also it is included in Modifer.classModifiers();  Modifer.CLASS_MODIFIERS.
it might be worth a note saying it is class file version specific.

-

PR: https://git.openjdk.org/jdk/pull/7445

Re: RFR: 8282664: Unroll by hand StringUTF16, StringLatin1, and Arrays polynomial hash loops [v14]

[Ludovic Henry]

On Thu, 12 May 2022 12:14:49 GMT, Ludovic Henry  wrote:

>> Despite the hash value being cached for Strings, computing the hash still 
>> represents a significant CPU usage for applications handling lots of text.
>> 
>> Even though it would be generally better to do it through an enhancement to 
>> the autovectorizer, the complexity of doing it by hand is trivial and the 
>> gain is sizable (2x speedup) even without the Vector API. The algorithm has 
>> been proposed by Richard Startin and Paul Sandoz [1].
>> 
>> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz`
>> 
>> 
>> Benchmark(size)  Mode  Cnt Score 
>>Error  Units
>> StringHashCode.Algorithm.scalarLatin1 0  avgt   25 2.111 
>> ±  0.210  ns/op
>> StringHashCode.Algorithm.scalarLatin1 1  avgt   25 3.500 
>> ±  0.127  ns/op
>> StringHashCode.Algorithm.scalarLatin110  avgt   25 7.001 
>> ±  0.099  ns/op
>> StringHashCode.Algorithm.scalarLatin1   100  avgt   2561.285 
>> ±  0.444  ns/op
>> StringHashCode.Algorithm.scalarLatin1  1000  avgt   25   628.995 
>> ±  0.846  ns/op
>> StringHashCode.Algorithm.scalarLatin1 1  avgt   25  6307.990 
>> ±  4.071  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16   0  avgt   25 2.358 
>> ±  0.092  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16   1  avgt   25 3.631 
>> ±  0.159  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16  10  avgt   25 7.049 
>> ±  0.019  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16 100  avgt   2533.626 
>> ±  1.218  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled161000  avgt   25   317.811 
>> ±  1.225  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled16   1  avgt   25  3212.333 
>> ± 14.621  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled80  avgt   25 2.356 
>> ±  0.097  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled81  avgt   25 3.630 
>> ±  0.158  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8   10  avgt   25 8.724 
>> ±  0.065  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8  100  avgt   2532.402 
>> ±  0.019  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled8 1000  avgt   25   321.949 
>> ±  0.251  ns/op
>> StringHashCode.Algorithm.scalarLatin1Unrolled81  avgt   25  3202.083 
>> ±  1.667  ns/op
>> StringHashCode.Algorithm.scalarUTF16  0  avgt   25 2.135 
>> ±  0.191  ns/op
>> StringHashCode.Algorithm.scalarUTF16  1  avgt   25 5.202 
>> ±  0.362  ns/op
>> StringHashCode.Algorithm.scalarUTF16 10  avgt   2511.105 
>> ±  0.112  ns/op
>> StringHashCode.Algorithm.scalarUTF16100  avgt   2575.974 
>> ±  0.702  ns/op
>> StringHashCode.Algorithm.scalarUTF16   1000  avgt   25   716.429 
>> ±  3.290  ns/op
>> StringHashCode.Algorithm.scalarUTF16  1  avgt   25  7095.459 
>> ± 43.847  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled160  avgt   25 2.381 
>> ±  0.038  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled161  avgt   25 5.268 
>> ±  0.422  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16   10  avgt   2511.248 
>> ±  0.178  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16  100  avgt   2552.966 
>> ±  0.089  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled16 1000  avgt   25   450.912 
>> ±  1.834  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled161  avgt   25  4403.988 
>> ±  2.927  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8 0  avgt   25 2.401 
>> ±  0.032  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8 1  avgt   25 5.091 
>> ±  0.396  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled810  avgt   2512.801 
>> ±  0.189  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8   100  avgt   2552.068 
>> ±  0.032  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8  1000  avgt   25   453.270 
>> ±  0.340  ns/op
>> StringHashCode.Algorithm.scalarUTF16Unrolled8 1  avgt   25  4433.112 
>> ±  2.699  ns/op
>> 
>> 
>> At Datadog, we handle a great amount of text (through logs management for 
>> example), and hashing String represents a large part of our CPU usage. It's 
>> very unlikely that we are the only one as String.hashCode is such a core 
>> feature of the JVM-based languages with its use in HashMap for example. 
>> Having even only a 2x speedup would allow us to save thousands of CPU cores 
>> per month and improve correspondingly the energy/carbon impact.
>> 
>> [1] 
>> https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf
>
> Ludovic Henry has updated the pull request incrementally with one additional 
> commit since 

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat [v4]

[Alan Bateman]

On Tue, 14 Jun 2022 12:18:52 GMT, Matthias Baesken  wrote:

>> When trying to construct an LdapURL object with a bad input string (in this 
>> example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we 
>> run into the exception below :
>> 
>> import com.sun.jndi.ldap.LdapURL;
>>  
>> String url = "ldap://ad_jbs.ttt.net:389/xyz;; // bad input string containing 
>> _
>> LdapURL ldapUrl = new LdapURL(url);
>> 
>> 
>> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
>> Exception in thread "main" javax.naming.NamingException: Cannot parse url: 
>> ldap://ad_jbs.ttt.net:389/xyz [Root exception is 
>> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
>> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:115)
>> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
>> Caused by: java.net.MalformedURLException: unsupported authority: 
>> ad_jbs.ttt.net:389
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
>> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
>> 
>> I would like to add the host and port info to the exception (in the example 
>> it is host:port of URI:null:-1] ) so that it is directly visible that the 
>> input caused the construction of a URI
>> with "special"/problematic host and port values.
>
> Matthias Baesken has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   avoid very long line

Marked as reviewed by alanb (Reviewer).

-

PR: https://git.openjdk.org/jdk/pull/9126

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat [v4]

[Daniel Fuchs]

On Tue, 14 Jun 2022 12:18:52 GMT, Matthias Baesken  wrote:

>> When trying to construct an LdapURL object with a bad input string (in this 
>> example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we 
>> run into the exception below :
>> 
>> import com.sun.jndi.ldap.LdapURL;
>>  
>> String url = "ldap://ad_jbs.ttt.net:389/xyz;; // bad input string containing 
>> _
>> LdapURL ldapUrl = new LdapURL(url);
>> 
>> 
>> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
>> Exception in thread "main" javax.naming.NamingException: Cannot parse url: 
>> ldap://ad_jbs.ttt.net:389/xyz [Root exception is 
>> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
>> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:115)
>> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
>> Caused by: java.net.MalformedURLException: unsupported authority: 
>> ad_jbs.ttt.net:389
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
>> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
>> 
>> I would like to add the host and port info to the exception (in the example 
>> it is host:port of URI:null:-1] ) so that it is directly visible that the 
>> input caused the construction of a URI
>> with "special"/problematic host and port values.
>
> Matthias Baesken has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   avoid very long line

The last changes LGTM.

-

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9126

Re: RFR: 8286176: Add JNI_VERSION_19 to jni.h and JNI spec

[David Holmes]

On Sat, 11 Jun 2022 15:42:34 GMT, Alan Bateman  wrote:

> JNI is updated in Java 19 so we need to define JNI_VERSION_19 and change 
> GetVersion to return this version.
> 
> test/hotspot/jtreg/native_sanity/JniVersion.java is updated to check that 
> JNI_VERSION_19 is returned. The native library in the JMX agent, and several 
> tests, define JNI_OnLoad that return JNI_VERSION_10 as the JNI version 
> needed. These are updated to return JNI_VERSION_19 although these updates 
> aren't strictly needed.

@AlanBateman  sorry I missed your statement "although these updates aren't 
strictly needed".

-

PR: https://git.openjdk.org/jdk19/pull/7

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat [v4]

[Matthias Baesken]

> When trying to construct an LdapURL object with a bad input string (in this 
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run 
> into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  
> String url = "ldap://ad_jbs.ttt.net:389/xyz;; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: 
> ldap://ad_jbs.ttt.net:389/xyz [Root exception is 
> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: 
> ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example 
> it is host:port of URI:null:-1] ) so that it is directly visible that the 
> input caused the construction of a URI
> with "special"/problematic host and port values.

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

  avoid very long line

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/9126/files
  - new: https://git.openjdk.org/jdk/pull/9126/files/bdbe2204..8f528226

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=9126=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9126=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9126/head:pull/9126

PR: https://git.openjdk.org/jdk/pull/9126

Re: Handling of USR2 signal in JVM on Linux

[Alan Bateman]

On 14/06/2022 10:44, Andrey Turbanov wrote:

Hello.
During investigation of signal handling in JVM (for
https://github.com/openjdk/jdk/pull/9100#discussion_r894992558 )
I found out that sending USR2 crashes my JDK. (Linux fastdebug x64)

kill -USR2 1346792

# assert(thread != __null) failed: Missing current thread in SR_handler
# Internal Error
(/home/turbanoff/Projects/official_jdk/src/hotspot/os/posix/signals_posix.cpp:1600),
pid=1346792, tid=1346792

Full hs_err_pid1346792.log:
https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a


Is it known/expected behaviour?
I found some description there
https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
that USR2 is used for SUSPEND/RESUME. Is it supported by Hotspot?


In general you have to be very careful when using signals. Yes, it can 
easily break things and probably notice it quickly with debug builds as 
asserts are compiled in to the builds (like the above). So I think 
you've found the right page to read up on this. In this case, you can 
set _JAVA_SR_SIGNUM to specify a different signal for S/R.


-Alan

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat [v3]

[Bernd Eckenfels]

The change does not seem to be related to your description, and the description 
does not match the shown exception. In fact the example stacktrace contains the 
authority value twice and your change adds a diagnostic which is not really 
helpful for the case of the underscore? I would not be too specific for such 
general parsing rules.


--
http://bernd.eckenfels.net

Von: core-libs-dev  im Auftrag von 
Matthias Baesken 
Gesendet: Tuesday, June 14, 2022 1:36:36 PM
An: core-libs-dev@openjdk.java.net ; 
security-...@openjdk.java.net 
Betreff: Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat 
[v3]

> When trying to construct an LdapURL object with a bad input string (in this 
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run 
> into the exception below :
>
> import com.sun.jndi.ldap.LdapURL;
>  
> String url = "ldap://ad_jbs.ttt.net:389/xyz;; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
>
>
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: 
> ldap://ad_jbs.ttt.net:389/xyz [Root exception is 
> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: 
> ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
>
> I would like to add the host and port info to the exception (in the example 
> it is host:port of URI:null:-1] ) so that it is directly visible that the 
> input caused the construction of a URI
> with "special"/problematic host and port values.

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

  fix copy paste error

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/9126/files
  - new: https://git.openjdk.org/jdk/pull/9126/files/1050c724..bdbe2204

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=9126=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9126=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9126/head:pull/9126

PR: https://git.openjdk.org/jdk/pull/9126

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat [v3]

[Alan Bateman]

On Tue, 14 Jun 2022 11:36:36 GMT, Matthias Baesken  wrote:

>> When trying to construct an LdapURL object with a bad input string (in this 
>> example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we 
>> run into the exception below :
>> 
>> import com.sun.jndi.ldap.LdapURL;
>>  
>> String url = "ldap://ad_jbs.ttt.net:389/xyz;; // bad input string containing 
>> _
>> LdapURL ldapUrl = new LdapURL(url);
>> 
>> 
>> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
>> Exception in thread "main" javax.naming.NamingException: Cannot parse url: 
>> ldap://ad_jbs.ttt.net:389/xyz [Root exception is 
>> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
>> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:115)
>> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
>> Caused by: java.net.MalformedURLException: unsupported authority: 
>> ad_jbs.ttt.net:389
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
>> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
>> 
>> I would like to add the host and port info to the exception (in the example 
>> it is host:port of URI:null:-1] ) so that it is directly visible that the 
>> input caused the construction of a URI
>> with "special"/problematic host and port values.
>
> Matthias Baesken has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   fix copy paste error

src/java.naming/share/classes/com/sun/jndi/toolkit/url/Uri.java line 368:

> 366: // throw if we have user info or regname
> 367: throw new MalformedURLException("Authority 
> component is not server-based, or contains user info. Unsupported authority: 
> " + auth);
> 368: }

This looks okay but you may have to split up the line to avoid adding a 150+ 
char line (most of the file seems to keep the lines under 100 or so).

-

PR: https://git.openjdk.org/jdk/pull/9126

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat [v2]

[Matthias Baesken]

On Tue, 14 Jun 2022 10:43:54 GMT, Matthias Baesken  wrote:

>> When trying to construct an LdapURL object with a bad input string (in this 
>> example the _ in ad_jbs is causing issues), and not using
>> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we 
>> run into the exception below :
>> 
>> import com.sun.jndi.ldap.LdapURL;
>>  
>> String url = "ldap://ad_jbs.ttt.net:389/xyz;; // bad input string containing 
>> _
>> LdapURL ldapUrl = new LdapURL(url);
>> 
>> 
>> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
>> Exception in thread "main" javax.naming.NamingException: Cannot parse url: 
>> ldap://ad_jbs.ttt.net:389/xyz [Root exception is 
>> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
>> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:115)
>> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
>> Caused by: java.net.MalformedURLException: unsupported authority: 
>> ad_jbs.ttt.net:389
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
>> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
>> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
>> 
>> I would like to add the host and port info to the exception (in the example 
>> it is host:port of URI:null:-1] ) so that it is directly visible that the 
>> input caused the construction of a URI
>> with "special"/problematic host and port values.
>
> Matthias Baesken has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Adjust exception text to the suggestion of Daniel Fuchs

> I guess there's been some copy paste mistake here :-)

Yes, had to fix that!

-

PR: https://git.openjdk.org/jdk/pull/9126

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat [v3]

[Matthias Baesken]

> When trying to construct an LdapURL object with a bad input string (in this 
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run 
> into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  
> String url = "ldap://ad_jbs.ttt.net:389/xyz;; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: 
> ldap://ad_jbs.ttt.net:389/xyz [Root exception is 
> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: 
> ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example 
> it is host:port of URI:null:-1] ) so that it is directly visible that the 
> input caused the construction of a URI
> with "special"/problematic host and port values.

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

  fix copy paste error

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/9126/files
  - new: https://git.openjdk.org/jdk/pull/9126/files/1050c724..bdbe2204

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=9126=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9126=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9126/head:pull/9126

PR: https://git.openjdk.org/jdk/pull/9126

Integrated: JDK-8288094: cleanup old _MSC_VER handling

[Matthias Baesken]

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken  wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of 
> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't 
> want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see 
> https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4
>  .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also 
> probably older than VS2015) would not be able to build jdk anymore.

This pull request has now been integrated.

Changeset: 0530f4e5
Author:Matthias Baesken 
URL:   
https://git.openjdk.org/jdk/commit/0530f4e517be5d5b3ff10be8a0764e564f068c06
Stats: 163 lines in 9 files changed: 0 ins; 149 del; 14 mod

8288094: cleanup old _MSC_VER handling

Reviewed-by: mdoerr, clanger, aturbanov

-

PR: https://git.openjdk.org/jdk/pull/9105

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat

[Matthias Baesken]

On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken  wrote:

> When trying to construct an LdapURL object with a bad input string (in this 
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run 
> into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  
> String url = "ldap://ad_jbs.ttt.net:389/xyz;; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: 
> ldap://ad_jbs.ttt.net:389/xyz [Root exception is 
> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: 
> ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example 
> it is host:port of URI:null:-1] ) so that it is directly visible that the 
> input caused the construction of a URI
> with "special"/problematic host and port values.

Thanks Daniel, I adjusted the exception message to what you suggested.

-

PR: https://git.openjdk.org/jdk/pull/9126

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat [v2]

[Matthias Baesken]

> When trying to construct an LdapURL object with a bad input string (in this 
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run 
> into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  
> String url = "ldap://ad_jbs.ttt.net:389/xyz;; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: 
> ldap://ad_jbs.ttt.net:389/xyz [Root exception is 
> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: 
> ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example 
> it is host:port of URI:null:-1] ) so that it is directly visible that the 
> input caused the construction of a URI
> with "special"/problematic host and port values.

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

  Adjust exception text to the suggestion of Daniel Fuchs

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/9126/files
  - new: https://git.openjdk.org/jdk/pull/9126/files/2454d4e5..1050c724

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=9126=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9126=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9126.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9126/head:pull/9126

PR: https://git.openjdk.org/jdk/pull/9126

Handling of USR2 signal in JVM on Linux

[Andrey Turbanov]

Hello.
During investigation of signal handling in JVM (for
https://github.com/openjdk/jdk/pull/9100#discussion_r894992558 )
I found out that sending USR2 crashes my JDK. (Linux fastdebug x64)

kill -USR2 1346792

# assert(thread != __null) failed: Missing current thread in SR_handler
# Internal Error
(/home/turbanoff/Projects/official_jdk/src/hotspot/os/posix/signals_posix.cpp:1600),
pid=1346792, tid=1346792

Full hs_err_pid1346792.log:
https://gist.github.com/turbanoff/2099327ea13357a90df43a2d6b0e2e6a


Is it known/expected behaviour?
I found some description there
https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html
that USR2 is used for SUSPEND/RESUME. Is it supported by Hotspot?


Andrey Turbanov

Re: RFR: 8288021: Add hard test cases to jdk.internal.math.DoubleToDecimalChecker

[Raffaello Giulietti]

On Wed, 8 Jun 2022 13:12:09 GMT, Raffaello Giulietti  
wrote:

> These 19'545 doubles were generated on purpose by Paul Zimmermann of INRIA as 
> hard test cases.

Many of the test cases failed before 
[PR3402](https://github.com/openjdk/jdk/pull/3402), so it's worth having them 
in the codebase to detect regressions.

-

PR: https://git.openjdk.org/jdk/pull/9084

Re: RFR: JDK-8288094: cleanup old _MSC_VER handling [v3]

[Andrey Turbanov]

On Mon, 13 Jun 2022 11:46:52 GMT, Matthias Baesken  wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of 
>> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't 
>> want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see 
>> https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4
>>  .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also 
>> probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   remove VS2005 comment in adlc

Marked as reviewed by aturbanov (Committer).

-

PR: https://git.openjdk.org/jdk/pull/9105

Re: RFR: JDK-8288094: cleanup old _MSC_VER handling [v3]

[Matthias Baesken]

On Mon, 13 Jun 2022 11:46:52 GMT, Matthias Baesken  wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of 
>> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't 
>> want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see 
>> https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4
>>  .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also 
>> probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   remove VS2005 comment in adlc

Hi Phil and Andrey are you fine with the current version of the PR ?

-

PR: https://git.openjdk.org/jdk/pull/9105

Re: RFR: 8287917: System.loadLibrary does not work on Big Sur if JDK is built with macOS SDK 10.15 and earlier [v2]

[Yoshiki Sato]

> Please review this PR.
> SDK 10.15 and earlier reports os.version as 10.16 on Big Sur.  This fix will 
> check if dynamic linker support, which is supported from Big Sur, is 
> available or not on the OS even if os.version is reported as 10.16 instead of 
> 11.  The os.version 10.16 doesn't include the update version like y of 
> 10.x.y.  Hence the change only see if it is 10.16 or not.

Yoshiki Sato has updated the pull request incrementally with one additional 
commit since the last revision:

  Update copyright end year

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/9077/files
  - new: https://git.openjdk.org/jdk/pull/9077/files/a9b95965..bdd97130

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=9077=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9077=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9077.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9077/head:pull/9077

PR: https://git.openjdk.org/jdk/pull/9077

Re: RFR: 8287917: System.loadLibrary does not work on Big Sur if JDK is built with macOS SDK 10.15 and earlier

[Yoshiki Sato]

On Fri, 10 Jun 2022 17:51:37 GMT, Mandy Chung  wrote:

>> Please review this PR.
>> SDK 10.15 and earlier reports os.version as 10.16 on Big Sur.  This fix will 
>> check if dynamic linker support, which is supported from Big Sur, is 
>> available or not on the OS even if os.version is reported as 10.16 instead 
>> of 11.  The os.version 10.16 doesn't include the update version like y of 
>> 10.x.y.  Hence the change only see if it is 10.16 or not.
>
> test/jdk/java/lang/RuntimeTests/loadLibrary/exeLibraryCache/LibraryFromCache.java
>  line 45:
> 
>> 43: public class LibraryFromCache {
>> 44: public static void main(String[] args) throws IOException {
>> 45: System.out.println("os.version = " + 
>> System.getProperty("os.version"));
> 
> The copyright end year needs to be updated.

Thanks for catching.

-

PR: https://git.openjdk.org/jdk/pull/9077

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v25]

[Joe Darcy]

> This is an early review of changes to better model JVM access flags, that is 
> "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but 
> distinct. There are concepts that overlap in the two domains (public, 
> private, etc.), others that only have a language-level modifier (sealed), and 
> still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these 
> subtleties. For example, the bit positions used by access flags on different 
> kinds of elements overlap (such as "volatile" for fields and "bridge" for 
> methods. Just having a raw integer does not provide sufficient context to 
> decode the corresponding language-level string. Methods like 
> Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like 
> Valhalla, addressing the existent modeling deficiency now ahead of time is 
> reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It 
> is missing implementations to map from, say, method modifiers to access 
> flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in 
> once the API is further along.

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

  Respond to review feedback.

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/75ac9c18..adcbcb71

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7445=24
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7445=23-24

  Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v20]

[Joe Darcy]

On Wed, 1 Jun 2022 05:09:42 GMT, ExE Boss  wrote:

>> Or `AbstractMethodError`, which is what `Executable::getParameterCount()` 
>> does:
>> https://github.com/openjdk/jdk/blob/e751b7b1b6f7269a1fe20c07748c726536388f6d/src/java.base/share/classes/java/lang/reflect/Executable.java#L248-L258
>
> Actually, it should probably be `UnsupportedOperationException` instead.

Hmm. If we had sealed classes and interfaces back in JDK 1.1 when Member was 
added, it most likely would have been added as sealed interface. But, we didn't 
have sealed interfaces back then so Member can (potentially) be extended by 
anyone. IIRC, there are a few classes implementing Member outside of the JDK.

So, when adding a new method would JDK 20, the method should certainly have be 
default method. I think throwing UnsupportedOperationException in the default 
is marginally better than the alternatives. I'll update the PR accordingly in a 
subsequent push. Thanks.

-

PR: https://git.openjdk.org/jdk/pull/7445

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v24]

[Joe Darcy]

On Tue, 14 Jun 2022 01:40:53 GMT, liach  wrote:

>> Joe Darcy has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Make mask fields final in ModuleDescriptor.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 300:
> 
>> 298: /**
>> 299:  * {@return a set of access flags for the given mask value
>> 300:  * appropriate for the location in question}
> 
> Should we specify that the returned set is unmodifiable/immutable?

Sure; that would be consistent with other parts of the PR.

-

PR: https://git.openjdk.org/jdk/pull/7445

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v4]

[Joe Darcy]

On Tue, 31 May 2022 17:23:18 GMT, Rémi Forax  wrote:

>> For completeness, I think including SUPER is reasonable, even though has 
>> been a no-op for some time. (Some time in the future, there could be a class 
>> file version aware additions to this enum class.) Well spotted omission.
>
> `ACC_SUPER`may be reconed as `ACC_IDENTITY`by Valhalla, so i'm not sure it's 
> a good idea to add ACC_SUPER.

As discussed elsewhere in the PR, given the historical existence of ACC_SUPER, 
I think it is reasonable to leave it all. Also, even if removed later in the 
release, it would be helpful to validate how overlapping flags can be handled 
in practice in Valhalla.

-

PR: https://git.openjdk.org/jdk/pull/7445

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v24]

[liach]

On Tue, 14 Jun 2022 01:25:02 GMT, Joe Darcy  wrote:

>> This is an early review of changes to better model JVM access flags, that is 
>> "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but 
>> distinct. There are concepts that overlap in the two domains (public, 
>> private, etc.), others that only have a language-level modifier (sealed), 
>> and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these 
>> subtleties. For example, the bit positions used by access flags on different 
>> kinds of elements overlap (such as "volatile" for fields and "bridge" for 
>> methods. Just having a raw integer does not provide sufficient context to 
>> decode the corresponding language-level string. Methods like 
>> Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like 
>> Valhalla, addressing the existent modeling deficiency now ahead of time is 
>> reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. 
>> It is missing implementations to map from, say, method modifiers to access 
>> flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in 
>> once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Make mask fields final in ModuleDescriptor.

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 127:

> 125:  * 0x0020}.
> 126:  */
> 127: SUPER(0x_0020, false, Set.of(Location.CLASS)),

Should we document that this flag won't appear in `Class#accessFlags` no matter 
if it's declared in the class file?

src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 300:

> 298: /**
> 299:  * {@return a set of access flags for the given mask value
> 300:  * appropriate for the location in question}

Should we specify that the returned set is unmodifiable/immutable?

-

PR: https://git.openjdk.org/jdk/pull/7445

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v24]

[Joe Darcy]

> This is an early review of changes to better model JVM access flags, that is 
> "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but 
> distinct. There are concepts that overlap in the two domains (public, 
> private, etc.), others that only have a language-level modifier (sealed), and 
> still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these 
> subtleties. For example, the bit positions used by access flags on different 
> kinds of elements overlap (such as "volatile" for fields and "bridge" for 
> methods. Just having a raw integer does not provide sufficient context to 
> decode the corresponding language-level string. Methods like 
> Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like 
> Valhalla, addressing the existent modeling deficiency now ahead of time is 
> reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It 
> is missing implementations to map from, say, method modifiers to access 
> flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in 
> once the API is further along.

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

  Make mask fields final in ModuleDescriptor.

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/fd682ac8..75ac9c18

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7445=23
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7445=22-23

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v20]

[Joe Darcy]

On Tue, 31 May 2022 17:20:08 GMT, Rémi Forax  wrote:

>> Joe Darcy 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 32 additional commits 
>> since the last revision:
>> 
>>  - Target JDK 20 rather than 19.
>>  - Merge branch 'master' into JDK-8266670
>>  - Add mask values to constants' javadoc.
>>  - Implement review feedback from mlchung.
>>  - Fix type in @throws tag.
>>  - Merge branch 'master' into JDK-8266670
>>  - Respond to review feedback.
>>  - Merge branch 'master' into JDK-8266670
>>  - Make workding changes suggested in review feedback.
>>  - Merge branch 'master' into JDK-8266670
>>  - ... and 22 more: https://git.openjdk.org/jdk/compare/3d668090...05cf2d8b
>
> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 130:
> 
>> 128: MANDATED(AccessFlag.MANDATED.mask());
>> 129: 
>> 130: private int mask;
> 
> it should be declared final ?

Sure; will change.

> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 134:
> 
>> 132: this.mask = mask;
>> 133: }
>> 134: private int mask() {return mask;}
> 
> seem useless, `mask` can be accessed directly

Hmm. Stylistically, I prefer methods.

-

PR: https://git.openjdk.org/jdk/pull/7445

Integrated: 8288378: [BACKOUT] DST not applying properly with zone id offset set with TZ env variable

[Naoto Sato]

On Tue, 14 Jun 2022 00:56:47 GMT, Naoto Sato  wrote:

> Backing out a fix that is causing a T1 failure.
> 
> This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.

This pull request has now been integrated.

Changeset: fbe92666
Author:Naoto Sato 
URL:   
https://git.openjdk.org/jdk/commit/fbe926662287283c579fdb4ca8290670500cf5a5
Stats: 95 lines in 2 files changed: 1 ins; 91 del; 3 mod

8288378: [BACKOUT] DST not applying properly with zone id offset set with TZ 
env variable

Reviewed-by: dholmes

-

PR: https://git.openjdk.org/jdk/pull/9151

RFR: 8288378: [BACKOUT] DST not applying properly with zone id offset set with TZ env variable

[Naoto Sato]

Backing out a fix that is causing a T1 failure.

This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.

-

Commit messages:
 - 8288378: [BACKOUT] DST not applying properly with zone id offset set with TZ 
env variable

Changes: https://git.openjdk.org/jdk/pull/9151/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9151=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288378
  Stats: 95 lines in 2 files changed: 1 ins; 91 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9151.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9151/head:pull/9151

PR: https://git.openjdk.org/jdk/pull/9151

Re: RFR: 8288378: [BACKOUT] DST not applying properly with zone id offset set with TZ env variable

[David Holmes]

On Tue, 14 Jun 2022 00:56:47 GMT, Naoto Sato  wrote:

> Backing out a fix that is causing a T1 failure.
> 
> This reverts commit 9b6d0a7e94fd18d302c559bec6f785d71a919a88.

Backout looks accurate - thanks.

-

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9151

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v23]

[Joe Darcy]

> This is an early review of changes to better model JVM access flags, that is 
> "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but 
> distinct. There are concepts that overlap in the two domains (public, 
> private, etc.), others that only have a language-level modifier (sealed), and 
> still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these 
> subtleties. For example, the bit positions used by access flags on different 
> kinds of elements overlap (such as "volatile" for fields and "bridge" for 
> methods. Just having a raw integer does not provide sufficient context to 
> decode the corresponding language-level string. Methods like 
> Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like 
> Valhalla, addressing the existent modeling deficiency now ahead of time is 
> reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It 
> is missing implementations to map from, say, method modifiers to access 
> flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in 
> once the API is further along.

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

  Correct STATIC vs STATIC_PHASE issue found in code review.

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/840edf2a..fd682ac8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7445=22
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7445=21-22

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

[Joe Darcy]

On Wed, 13 Apr 2022 21:21:25 GMT, liach  wrote:

>> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 167:
>> 
>>> 165:  * but is optional in the dynamic phase, during execution.
>>> 166:  */
>>> 167: STATIC(AccessFlag.STATIC.mask()),
>> 
>> This is actually `AccessFlag.STATIC_PHASE` (`0x0040`), and not 
>> `AccessFlag.STATIC` (`0x0008`):
>> Suggestion:
>> 
>> STATIC(AccessFlag.STATIC_PHASE.mask()),
>
>> In the current hodgepodge AccessFlag, we have STATIC and STATIC_PHASE, and 
>> the incorrect ModuleDescriptor.accessFlags().contains(AccessFlag.STATIC) 
>> call is much more subtle, especially to new users of this class. Arguably, 
>> this misuse would be way worse than that in the distinct enum case.
> 
> Oops, didn't know this already happened. Good spot right there.

Corrected to STATIC_PHASE in subsequent push; thanks.

-

PR: https://git.openjdk.org/jdk/pull/7445

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v22]

[Joe Darcy]

> This is an early review of changes to better model JVM access flags, that is 
> "modifiers" like public, protected, etc. but explicitly at a VM level.
> 
> Language level modifiers and JVM level access flags are closely related, but 
> distinct. There are concepts that overlap in the two domains (public, 
> private, etc.), others that only have a language-level modifier (sealed), and 
> still others that only have an access flag (synthetic).
> 
> The existing java.lang.reflect.Modifier class is inadequate to model these 
> subtleties. For example, the bit positions used by access flags on different 
> kinds of elements overlap (such as "volatile" for fields and "bridge" for 
> methods. Just having a raw integer does not provide sufficient context to 
> decode the corresponding language-level string. Methods like 
> Modifier.methodModifiers() were introduced to cope with this situation.
> 
> With additional modifiers and flags on the horizon with projects like 
> Valhalla, addressing the existent modeling deficiency now ahead of time is 
> reasonable before further strain is introduced.
> 
> This PR in its current form is meant to give the overall shape of the API. It 
> is missing implementations to map from, say, method modifiers to access 
> flags, taking into account overlaps in bit positions.
> 
> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in 
> once the API is further along.

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

  From review feedback, use package-private contstants in Modifier.

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/7445/files
  - new: https://git.openjdk.org/jdk/pull/7445/files/111c6014..840edf2a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=7445=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7445=20-21

  Stats: 15 lines in 1 file changed: 0 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/7445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445

PR: https://git.openjdk.org/jdk/pull/7445

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v4]

[Joe Darcy]

On Tue, 15 Feb 2022 09:06:02 GMT, ExE Boss  wrote:

>> Joe Darcy has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Respond to more review feedback.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 163:
> 
>> 161: * @see Class#isEnum()
>> 162: */
>> 163: ENUM(0x4000, false, Set.of(TYPE, FIELD)),
> 
> These can use the **package‑private** constant fields from 
> `java.lang.reflect.Modifier`: 
> 

Good suggestion; will be reflected in the next push.

-

PR: https://git.openjdk.org/jdk/pull/7445

Re: RFR: 8287186: JDK modules participating in preview [v3]

[Paul Sandoz]

> Allow JDK modules that use preview features (preview language features or 
> preview API features from dependent modules) to participate without the need 
> to compile with `--enable-preview`.
> 
> It's difficult to enable participation using an annotation due to the nature 
> in which symbols are encountered when processing source as there is no 
> guaranteed order to the processing of certain symbols.
> 
> Instead a JDK module participates if the `java.base` package 
> `jdk.internal.javac` is exported to that module (@lahodaj clever idea!). An 
> internal annotation `jdk.internal.javac.ParticipatesInPreview` can be 
> declared on the module. Such a declaration cannot be enforced but does by its 
> use require the `jdk.internal.javac`'s export list to be updated.
> 
> The modules `jdk.incubator.vector` and `jdk.incubator.concurrent` have been 
> updated accordingly, both of which participate in preview APIs (APIs in 
> `java.lang.foreign` and `Thread.ofVirtual`, respectively).

Paul Sandoz 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 four additional commits since 
the last revision:

 - Merge remote-tracking branch 'upstream/master' into 
JDK-8287186-preview-participating
 - Let java.management participate in preview features.
 - Unused import.
 - Generalize the pariticipating in preview APIs.

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/9087/files
  - new: https://git.openjdk.org/jdk/pull/9087/files/9defdf23..abd1fbf6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=9087=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9087=01-02

  Stats: 17219 lines in 554 files changed: 13408 ins; 1651 del; 2160 mod
  Patch: https://git.openjdk.org/jdk/pull/9087.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9087/head:pull/9087

PR: https://git.openjdk.org/jdk/pull/9087

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat

[Matthias Baesken]

On Mon, 13 Jun 2022 14:29:44 GMT, Jaikiran Pai  wrote:

> > Hi Daniel, should we maybe better print something like "check for not 
> > allowed characters" in the exception ? Do you have an easy and cheap way in 
> > mind to the get the unsupported character (in this case "_") to add it to 
> > the output ? Would maybe be more helpful than the proposed host:port and 
> > better regarding security concerns.
> 
> Hello Matthias, the current error message is:
> 
> > java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389
> 
> Are you suggesting that the error message should include some additional 
> wording which states why the authority isn't supported (in this case because 
> of the presence of that `_` character)?

Yes , this is what I meant.  Ideally (and if it is not much overhead/easy to 
get) we show the 'bad'  character in the message.  Otherwise just some 
additional wording.

-

PR: https://git.openjdk.org/jdk/pull/9126

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat

[Jaikiran Pai]

On Mon, 13 Jun 2022 07:26:32 GMT, Matthias Baesken  wrote:

> Hi Daniel, should we maybe better print something like "check for not allowed 
> characters" in the exception ? Do you have an easy and cheap way in mind to 
> the get the unsupported character (in this case "_") to add it to the output 
> ? Would maybe be more helpful than the proposed host:port and better 
> regarding security concerns.

Hello Matthias, the current error message is:

> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389

Are you suggesting that the error message should include some additional 
wording which states why the authority isn't supported (in this case because of 
the presence of that `_` character)?

-

PR: https://git.openjdk.org/jdk/pull/9126

RFR: 8286176: Add JNI_VERSION_19 to jni.h and JNI spec

[Alan Bateman]

JNI is updated in Java 19 so we need to define JNI_VERSION_19 and change 
GetVersion to return this version.

test/hotspot/jtreg/native_sanity/JniVersion.java is updated to check that 
JNI_VERSION_19 is returned. The native library in the JMX agent, and several 
tests, define JNI_OnLoad that return JNI_VERSION_10 as the JNI version needed. 
These are updated to return JNI_VERSION_19 although these updates aren't 
strictly needed.

-

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk19/pull/7/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk19=7=00
  Issue: https://bugs.openjdk.org/browse/JDK-8286176
  Stats: 16 lines in 10 files changed: 2 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk19/pull/7.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/7/head:pull/7

PR: https://git.openjdk.org/jdk19/pull/7

Re: [Very fast List/Deque to java.util?]

[John Hendrikx]

I took a look.

I found a few results odd:

|com.github.coderodde.util.IndexedLinkedList.addLast in (ms): 8 
java.util.LinkedList.addLast in (ms): 2 java.util.ArrayList.addLast in 
(ms): 157 org.apache.commons.collections4.list.TreeList.addLast in (ms): 38|


Basically, ArrayList's performance (which should be O(1) in this case) 
is surprising. Looking at the benchmark, it is calling 
ArrayList#add(int, E) -- this method is not special cased for adding at 
the end of the list (it will do a range check and call System#arrayCopy 
in all cases).


|com.github.coderodde.util.IndexedLinkedList.stream() in (ms): 1 
java.util.LinkedList.stream() in (ms): 20 java.util.ArrayList.stream() 
in (ms): 16 org.apache.commons.collections4.list.TreeList.stream() in 
(ms): 15|


This test isn't only measuring streaming (iteration?) but also 
re-inserting all elements back into a List 
(collect(Collectors.toList()). What I find odd is that the 
IndexedLinkedList would perform much better here than ArrayList, given 
that the time is probably dominated by the final collect, and not the 
iteration itself.  Is ArrayList#stream poorly optimized or is something 
else going on?


A pure iteration test would be interesting to see.

I also ran the benchmark on my machine. The benchmark on Github doesn't 
mention with what parameters it is run, and so when I run it I get quite 
different results. The committed version of the benchmark seems to use 
collections with a max size of 20 elements. The total time when I run 
the benchmark favors TreeList more than any other:


--- Total time elapsed ---
com.github.coderodde.util.IndexedLinkedList in (ms): 207
java.util.LinkedList in (ms): 4248
java.util.ArrayList in (ms): 1799
org.apache.commons.collections4.list.TreeList in (ms): 159

That said, I think there might be a place for a new list implementation 
in the JDK.  One use case I've had in the past was for a list that is 
always sorted but also allows index based access when displaying a 
window into the list. A TreeMap satisfies the sorting criteria but 
doesn't offer index access, while a plain ArrayList doesn't lend itself 
well for doing sorted inserts/removals (locating the correct location is 
trivial enough, but the actual insert or removal results in a 
potentially large copy).  Apache's TreeList is fairly good at this use case.


--John


On 13/06/2022 09:56, Rodion Efremov wrote:

Hello,

I have this List/Deque implementation [1] that (in a versatile benchmark)
runs much faster than ArrayList/LinkedList. Under mild assumptions, it
accesses an element in O(sqrt(N)) time.

Now, if all we want to do is to add at the tail and read via get(int
index), you are better of using java.util.ArrayList. If you wish to iterate
a list removing some elements, the way to go is to use java.util.LinkedList.

  However,, if you deal with larger lists via many different operations
(addFirst/addLast/add(int, E)/get(int)/remove(int)/ettc. my
IndexedLinkedLiist will outperform both of them gracefully.

So, what do you think? Does it deserve to become a class candidate for
java.util?

[1]https://github.com/coderodde/IndexedLinkedList

Re: RFR: JDK-8288094: cleanup old _MSC_VER handling [v3]

[Matthias Baesken]

> We still handle at a number of places ancient historic _MSC_VER versions of 
> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't 
> want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see 
> https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4
>  .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also 
> probably older than VS2015) would not be able to build jdk anymore.

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

  remove VS2005 comment in adlc

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/9105/files
  - new: https://git.openjdk.org/jdk/pull/9105/files/e97c8329..97659965

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=9105=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9105=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9105.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9105/head:pull/9105

PR: https://git.openjdk.org/jdk/pull/9105

Re: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]

[Matthias Baesken]

On Mon, 13 Jun 2022 10:33:24 GMT, Andrey Turbanov  wrote:

>> Matthias Baesken has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   use round directly
>
> src/hotspot/share/adlc/main.cpp line 491:
> 
>> 489: }
>> 490: 
>> 491: // VS2005 has its own definition, identical to this one.
> 
> Let's adjust comment too. No need to mention VS2005.

Thanks for the hint, I removed the VS2005 related comment.

-

PR: https://git.openjdk.org/jdk/pull/9105

Re: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]

[Andrey Turbanov]

On Mon, 13 Jun 2022 07:24:52 GMT, Matthias Baesken  wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of 
>> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't 
>> want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see 
>> https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4
>>  .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also 
>> probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   use round directly

src/hotspot/share/adlc/main.cpp line 491:

> 489: }
> 490: 
> 491: // VS2005 has its own definition, identical to this one.

Let's adjust comment too. No need to mention VS2005.

-

PR: https://git.openjdk.org/jdk/pull/9105

Re: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]

[Martin Doerr]

On Mon, 13 Jun 2022 07:24:52 GMT, Matthias Baesken  wrote:

>> We still handle at a number of places ancient historic _MSC_VER versions of 
>> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't 
>> want to adjust.
>> 
>> Currently still supported ("valid") VS version are 2017+, see 
>> https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4
>>  .
>> VALID_VS_VERSIONS="2019 2017 2022"
>> Even with adjusted toolchain m4 files, something older than VS2013 (also 
>> probably older than VS2015) would not be able to build jdk anymore.
>
> Matthias Baesken has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   use round directly

Nice!

-

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9105

Re: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v3]

[Severin Gehwolf]

On Wed, 8 Jun 2022 12:09:27 GMT, Severin Gehwolf  wrote:

>> Please review this cleanup change in the cgroup subsystem which used to use 
>> hard-coded stack allocated
>> buffers for concatenating strings in memory. We can use `stringStream` 
>> instead which doesn't have the issue
>> of hard-coding maximum lengths (and related checks) and makes the code, 
>> thus, easier to read.
>> 
>> While at it, I've written basic `gtests` verifying current behaviour (and 
>> the same for the JDK code). From
>> a functionality point of view this is a no-op (modulo the one bug in the 
>> substring case which seems to be
>> there since day one). I'd prefer if we could defer any change in 
>> functionality to a separate bug as this is
>> meant to only use stringStream throughout the cgroups code.
>> 
>> Testing:
>> - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2
>> - [x] Added tests, which I've verified also pass before the stringStream 
>> change
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Remove fix for substring match

@erikj79 Do you know why the SKARA bots didn't move this to `ready` by now? Is 
there an issue with the bots? Thanks!

-

PR: https://git.openjdk.org/jdk/pull/8969

Re: RFR: 8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX [v2]

[Andrey Turbanov]

On Sun, 15 May 2022 10:31:20 GMT, Andrey Turbanov  wrote:

>> TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster.
>> Compared via JMH benchmark: 150ns -> 125ns/op
>> 
>> Benchamark adapted from 
>> http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java
>> 
>> 
>> @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
>> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
>> @Fork(1)
>> @State(Scope.Thread)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class TimeUnitBench {
>> 
>> static final int SIZE = TimeUnit.values().length * 10;
>> 
>> @Param({"0", "1", "2", "3", "4", "5", "6", "-1"})
>> int bias;
>> 
>> TimeUnit[] mod;
>> 
>> @Setup
>> public void setup() {
>> mod = new TimeUnit[SIZE];
>> 
>> TimeUnit[] vals = TimeUnit.values();
>> for (int c = 0; c < SIZE; c++) {
>> if (bias == -1) {
>> // megamorphic
>> mod[c] = vals[c % vals.length];
>> } else {
>> mod[c] = vals[bias];
>> }
>> }
>> 
>> Random r = new Random();
>> for (int c = 0; c < 1; c++) {
>> int i = r.nextInt();
>> for (int o = 0; o < vals.length; o++) {
>> if (vals[o].toNanos(i) != TimeUnit.NANOSECONDS.convert(i, 
>> vals[o]))
>> throw new IllegalStateException("switch " + o);
>> }
>> }
>> }
>> 
>> @Benchmark
>> public void const_convert(Blackhole bh) {
>> for (TimeUnit tu : mod) {
>> bh.consume(do_convert(tu));
>> }
>> }
>> 
>> @Benchmark
>> public void value_convert(Blackhole bh) {
>> for (TimeUnit tu : mod) {
>> bh.consume(do_convert(tu, 1L));
>> }
>> }
>> 
>> @Benchmark
>> public void const_toNanos(Blackhole bh) {
>> for (TimeUnit tu : mod) {
>> bh.consume(do_toNanos(tu));
>> }
>> }
>> 
>> @Benchmark
>> public void value_toNanos(Blackhole bh) {
>> for (TimeUnit tu : mod) {
>> bh.consume(do_toNanos(tu, 1L));
>> }
>> }
>> 
>> @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>> private long do_toNanos(TimeUnit tu) {
>> return tu.toNanos(1L);
>> }
>> 
>> @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>> private long do_toNanos(TimeUnit tu, long value) {
>> return tu.toNanos(value);
>> }
>> 
>> @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>> private long do_convert(TimeUnit tu) {
>> return TimeUnit.NANOSECONDS.convert(1L, tu);
>> }
>> 
>> @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>> private long do_convert(TimeUnit tu, long value) {
>> return TimeUnit.NANOSECONDS.convert(value, tu);
>> }
>> }
>> 
>> Results:
>> 
>> Benchmark(bias)  Mode  CntScoreError  Units
>> TimeUnitBench.const_convert   0  avgt5  151,856 ± 28,595  ns/op
>> TimeUnitBench.const_convert   1  avgt5  150,720 ± 23,863  ns/op
>> TimeUnitBench.const_convert   2  avgt5  151,432 ± 23,184  ns/op
>> TimeUnitBench.const_convert   3  avgt5  150,959 ± 24,726  ns/op
>> TimeUnitBench.const_convert   4  avgt5  150,966 ± 25,280  ns/op
>> TimeUnitBench.const_convert   5  avgt5  150,976 ± 25,542  ns/op
>> TimeUnitBench.const_convert   6  avgt5  151,118 ± 25,254  ns/op
>> TimeUnitBench.const_convert  -1  avgt5  152,673 ± 29,861  ns/op
>> TimeUnitBench.const_toNanos   0  avgt5  121,296 ± 25,236  ns/op
>> TimeUnitBench.const_toNanos   1  avgt5  121,707 ± 25,364  ns/op
>> TimeUnitBench.const_toNanos   2  avgt5  121,736 ± 25,726  ns/op
>> TimeUnitBench.const_toNanos   3  avgt5  121,822 ± 25,491  ns/op
>> TimeUnitBench.const_toNanos   4  avgt5  121,867 ± 26,090  ns/op
>> TimeUnitBench.const_toNanos   5  avgt5  121,927 ± 25,611  ns/op
>> TimeUnitBench.const_toNanos   6  avgt5  121,821 ± 25,843  ns/op
>> TimeUnitBench.const_toNanos  -1  avgt5  121,923 ± 25,206  ns/op
>> TimeUnitBench.value_convert   0  avgt5  150,525 ± 25,439  ns/op
>> TimeUnitBench.value_convert   1  avgt5  151,098 ± 24,024  ns/op
>> TimeUnitBench.value_convert   2  avgt5  151,259 ± 25,381  ns/op
>> TimeUnitBench.value_convert   3  avgt5  151,030 ± 25,548  ns/op
>> TimeUnitBench.value_convert   4  avgt5  151,290 ± 25,998  ns/op
>> TimeUnitBench.value_convert   5  avgt5  151,006 ± 25,448  ns/op
>> TimeUnitBench.value_convert   6  avgt5  150,945 ± 25,314  ns/op
>> TimeUnitBench.value_convert  -1  avgt5  151,186 ± 25,814  ns/op
>> TimeUnitBench.value_toNanos   0  avgt5  121,556 ± 25,745  ns/op
>> TimeUnitBench.value_toNanos   1  avgt5  123,410 ± 22,323  ns/op
>> TimeUnitBench.value_toNanos   2  avgt5  125,452 

[Very fast List/Deque to java.util?]

[Rodion Efremov]

Hello,

I have this List/Deque implementation [1] that (in a versatile benchmark)
runs much faster than ArrayList/LinkedList. Under mild assumptions, it
accesses an element in O(sqrt(N)) time.

Now, if all we want to do is to add at the tail and read via get(int
index), you are better of using java.util.ArrayList. If you wish to iterate
a list removing some elements, the way to go is to use java.util.LinkedList.

 However,, if you deal with larger lists via many different operations
(addFirst/addLast/add(int, E)/get(int)/remove(int)/ettc. my
IndexedLinkedLiist will outperform both of them gracefully.

So, what do you think? Does it deserve to become a class candidate for
java.util?

[1] https://github.com/coderodde/IndexedLinkedList

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat

[Matthias Baesken]

On Fri, 10 Jun 2022 14:19:27 GMT, Daniel Fuchs  wrote:

> I might question whether the added "null:-1" information is really helpful, 
> or just as confusing however.

Hi Daniel, should we maybe better print something like "check for not allowed 
characters" in the exception ? Do you have an easy and cheap way in mind to the 
get the unsupported character (in this case "_") to add it to the output ? 
Would maybe be more helpful than the proposed host:port and better regarding 
security concerns.

-

PR: https://git.openjdk.org/jdk/pull/9126

Re: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]

[Matthias Baesken]

On Fri, 10 Jun 2022 21:04:04 GMT, Phil Race  wrote:

>> Matthias Baesken has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   use round directly
>
> src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 38:
> 
>> 36: #  define ROUND_TO_INT(num)((int) round(num))
>> 37: #else
>> 38: #  define ROUND_TO_INT(num)((int) floor((num) + 0.5))
> 
> If you look at when and why this was introduced (*), the "else" was not to 
> support some other compiler - it was to support the older MS compiler. So if 
> you don't want that, then the whole thing reduces to
> #define ROUND_TO_INT(num) ((int) round(num))
> 
> .. you could even go further and eliminate the macro altogether if it makes 
> sense - you'd have to look at the usages.
> 
> Same logic applies to the other files.
> 
> 
> (*) https://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010889.html

Hi Phil, I simplified the code more and now use round directly.

-

PR: https://git.openjdk.org/jdk/pull/9105

Re: RFR: JDK-8288094: cleanup old _MSC_VER handling [v2]

[Matthias Baesken]

> We still handle at a number of places ancient historic _MSC_VER versions of 
> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't 
> want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see 
> https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4
>  .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also 
> probably older than VS2015) would not be able to build jdk anymore.

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

  use round directly

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/9105/files
  - new: https://git.openjdk.org/jdk/pull/9105/files/ee8dc996..e97c8329

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=9105=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9105=00-01

  Stats: 21 lines in 3 files changed: 0 ins; 17 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9105.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9105/head:pull/9105

PR: https://git.openjdk.org/jdk/pull/9105

Re: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code [v3]

[Ioi Lam]

On Wed, 8 Jun 2022 12:09:27 GMT, Severin Gehwolf  wrote:

>> Please review this cleanup change in the cgroup subsystem which used to use 
>> hard-coded stack allocated
>> buffers for concatenating strings in memory. We can use `stringStream` 
>> instead which doesn't have the issue
>> of hard-coding maximum lengths (and related checks) and makes the code, 
>> thus, easier to read.
>> 
>> While at it, I've written basic `gtests` verifying current behaviour (and 
>> the same for the JDK code). From
>> a functionality point of view this is a no-op (modulo the one bug in the 
>> substring case which seems to be
>> there since day one). I'd prefer if we could defer any change in 
>> functionality to a separate bug as this is
>> meant to only use stringStream throughout the cgroups code.
>> 
>> Testing:
>> - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2
>> - [x] Added tests, which I've verified also pass before the stringStream 
>> change
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Remove fix for substring match

Just came back from vacation. LGTM.

-

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.org/jdk/pull/8969

Addition to MethodHandle: invokeExactUnchecked(()

[Kevinjeet Gill]

At present, MethodHandle's invokeExact() is declared as the following:

>From [1]:

> @IntrinsicCandidate
> public final native @PolymorphicSignature Object invokeExact(Object...
> args) throws Throwable;


I think this is a case where this method should probably never have
thrown a checked exception and I'd like to make the case and
test the waters and see if others have the appetite to see this change. I'm
assuming that altering this function signature is a no-go and a new
invokeExactUnchecked() is preferable.

Making the Case

I know, I know there's no PL bikeshed greater than that checked vs
unchecked exceptions -- looking at you, Future.get() -- but I think this
case is fundamentally different. MethodHandles are kindof a low-level niche
unit of JVM magic. That's why it's already an *exceptional* function given
its @PolymorphicSignature. Pun intended.

Most APIs for general use *should* drive good, sane programming habits, but
if you're reaching for MethodHandles you're probably doing something you
want a good deal of control over. There are a ton of ways it's already
expected to be a "just trust me" escape hatch already. MethodHandles are
often used with the expectation that they have to be static finals for them
to be inlined as if they are regular code. It is very awkward
and counter-productive even to have to introduce a *try { } catch(Throwable
e) { } *with all of its syntactic, bytecode, *and* JIT/inlining baggage.
Just throwing the invokeExact() call in a function or a lambda to mask out
the try-catch just pours back the layers you're futzing around with
MethoHandles to peel back.

If there's an interest and an appetite for it I'd love to take a crack at
implementing it. Any pointers are welcome!

[0]: https://bugs.openjdk.java.net/browse/JDK-8254354
[1]:
https://github.com/openjdk/jdk/blame/master/src/java.base/share/classes/java/lang/invoke/MethodHandle.java

Re: Very fast List/Deque to java.util?

[Rob Spoor]

I'd like to point out that rodde has also asked this project to be 
included in Apache Commons Collections: 
https://lists.apache.org/thread/klwtkbz96rp9zfr1077sc9r8tjtthfl4



On 11/06/2022 15:53, - wrote:

Hello,


What do you think?


First, for your benchmarks, I recommend you write them with
https://github.com/openjdk/jmh, a library that allows configuration of
warmup time, number of trials, and has utilities that avoid jvm
optimization's impact on your benchmarks.

A few cents: I recall seeing a similar proposal before. This
implementation is definitely superior to the Linked List as an
implementation of both deque and list at the cost of an extra finger
array allocation, but it probably won't excel compared to dedicated
Deque or List implementations in terms of performance and memory
usage.

Modern JDK List/Deque users usually use the array-focused
implementations like ArrayDeque and ArrayList; even though ArrayList
is slow at adding or removing at non-tail, most usages of ArrayList is
iterating and sometimes adding (predominantly at tail). Array
iteration is better optimized by hardware due to arrays. Thus,
LinkedList is already out-of-favor like Vector, and there are relevant
discussions in https://github.com/openjdk/jdk/pull/2744. The
doubly-linked structure of the finger list is at a natural
disadvantage (for iteration) here.

Even though this finger list won't be a replacement for ArrayList or
ArrayDeque, I wonder if it can be modified to become a concurrent
collection, so that modifications to the list can be synchronized by
the intervals between fingers. If it can, it would probably provide an
efficient concurrent list implementation compared to the current
CopyOnWriteArrayList, even though your current implementation seems
not to support concurrency.


Does it deserve to be included in JDK?


Let's revisit your proposal again: if it's in the JDK, where will it
be used? After all, JDK is a library that is used by millions or
billions of programs. Feel free to come up with a few use cases and we
will see if this finger list is the best for those cases.

On Sat, Jun 11, 2022 at 2:39 AM Rodion Efremov  wrote:


Hi,

I have this List/Deque implementation that runs (in a rather versatile
benchmark) much faster than ArrayList and LinkedList:

https://github.com/coderodde/IndexedLinkedList

What do you think? Does it deserve to be included in JDK?

Best regards,
rodde

Re: Very fast List/Deque to java.util?

[-]

Hello,

> What do you think?

First, for your benchmarks, I recommend you write them with
https://github.com/openjdk/jmh, a library that allows configuration of
warmup time, number of trials, and has utilities that avoid jvm
optimization's impact on your benchmarks.

A few cents: I recall seeing a similar proposal before. This
implementation is definitely superior to the Linked List as an
implementation of both deque and list at the cost of an extra finger
array allocation, but it probably won't excel compared to dedicated
Deque or List implementations in terms of performance and memory
usage.

Modern JDK List/Deque users usually use the array-focused
implementations like ArrayDeque and ArrayList; even though ArrayList
is slow at adding or removing at non-tail, most usages of ArrayList is
iterating and sometimes adding (predominantly at tail). Array
iteration is better optimized by hardware due to arrays. Thus,
LinkedList is already out-of-favor like Vector, and there are relevant
discussions in https://github.com/openjdk/jdk/pull/2744. The
doubly-linked structure of the finger list is at a natural
disadvantage (for iteration) here.

Even though this finger list won't be a replacement for ArrayList or
ArrayDeque, I wonder if it can be modified to become a concurrent
collection, so that modifications to the list can be synchronized by
the intervals between fingers. If it can, it would probably provide an
efficient concurrent list implementation compared to the current
CopyOnWriteArrayList, even though your current implementation seems
not to support concurrency.

> Does it deserve to be included in JDK?

Let's revisit your proposal again: if it's in the JDK, where will it
be used? After all, JDK is a library that is used by millions or
billions of programs. Feel free to come up with a few use cases and we
will see if this finger list is the best for those cases.

On Sat, Jun 11, 2022 at 2:39 AM Rodion Efremov  wrote:
>
> Hi,
>
> I have this List/Deque implementation that runs (in a rather versatile
> benchmark) much faster than ArrayList and LinkedList:
>
> https://github.com/coderodde/IndexedLinkedList
>
> What do you think? Does it deserve to be included in JDK?
>
> Best regards,
> rodde

Re: RFR: 8287696: Avoid redundant Hashtable.containsKey call in JarVerifier.doneWithMeta

[Andrey Turbanov]

On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov  wrote:

> Hashtable doesn't allow `null` values. So, instead of pair 
> `containsKey`/`remove` calls, we can directly call `remove` and then compare 
> result with `null`.
> https://github.com/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f08/src/java.base/share/classes/java/util/jar/JarVerifier.java#L433-L436

Thank you for review!

-

PR: https://git.openjdk.org/jdk/pull/8935

Integrated: 8287696: Avoid redundant Hashtable.containsKey call in JarVerifier.doneWithMeta

[Andrey Turbanov]

On Sat, 28 May 2022 12:00:00 GMT, Andrey Turbanov  wrote:

> Hashtable doesn't allow `null` values. So, instead of pair 
> `containsKey`/`remove` calls, we can directly call `remove` and then compare 
> result with `null`.
> https://github.com/openjdk/jdk/blob/2c461acfebd28fe5ef62805cbb004f91a3b18f08/src/java.base/share/classes/java/util/jar/JarVerifier.java#L433-L436

This pull request has now been integrated.

Changeset: f1143b1b
Author:Andrey Turbanov 
URL:   
https://git.openjdk.org/jdk/commit/f1143b1b57683665c81d24ff192a9babc30f28ea
Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod

8287696: Avoid redundant Hashtable.containsKey call in JarVerifier.doneWithMeta

Reviewed-by: jpai, lancea

-

PR: https://git.openjdk.org/jdk/pull/8935

Re: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle [v2]

[Peter Levart]

On Sat, 11 Jun 2022 07:55:52 GMT, Peter Levart  wrote:

>> Oops, yes you are correct!
>
> Hi,
> I think the synchronized block was redundant already in original code. Since 
> the entire handle method is `static synchronized` and it is the only method 
> that modifies the `handlers` and `signals` maps.
> But even with so much redundant synchronization, the Signal class is not 
> without races. There are multiple possible races in `dispatch(int number)` 
> method which is called from native code to dispatch a signal:
> - race no. 1: dispatch method (not synchronized) performs 2 independent 
> lookups into `signals` and `handlers` maps respectively, assuming their 
> inter-referenced state is consistent. But `handle` method may be concurrently 
> modifying them, so `dispatch` may see updated state of `signals` map while 
> seeing old state of `handlers` map or vice versa.
> - race  no. 2: besides `signals` and `handlers` there is a 3rd map in native 
> code, updated with `handle0` native method. Native code dispatches signals 
> according to that native map, forwarding them to either native handlers or to 
> `dispatch` Java method. But `handle` method may be modifying that native map 
> concurrently, so dispatch may be called as a consequence of updated native 
> map while seeing old states of `signals` and `handlers` maps.
> 
> I'm sure I might have missed some additional races.
> 
> How to fix this? Is it even necessary? I think that this internal API is not 
> used frequently so this was hardly an issue. But anyway, it would be a 
> challenge. While the two java maps: `handlers` and `signals` could be 
> replaced with a single map, there is the 3rd map in native code. We would not 
> want to make `dispatch` method synchronized, so with careful ordering of 
> modifications it is perhaps possible to account for races and make them 
> harmless...
> WDYT?

Well, studying this further, I think some races are already accounted for and 
are harmless except one. The `handle` method 1st attempts to register handler 
in native code via call to `handle0` and then updates the `signals` map.. As 
soon as native code registers the handler, `dispatch` may be called and the 
lookup into `signals` map may return null which would cause NPE in the 
following lookup into `handlers` map. So there are two possibilities to fix 
this:
- guard for null result from `singnals` lookup, or
- swap the order of modifying the `signals` map and a call to `handle0` native 
method. You could even update the `signals` map with `.putIfAbsent()` to avoid 
multiple reassignment with otherwise equal instances. This may unnecessarily 
establish a mapping for a Signal the can later not be registered, so you can 
remove it from the `signals` map in that case to clean-up.
The possible case when the lookup into `handlers` map returns null Handler is 
already taken into account, but there is a possible case where a NativeHandler 
is replaced with a java Handler implementation and `dispatch` is therefore 
already called, but `handlers` map lookup still returns a NativeHandler. In 
that case the NativeHandler::handle method will throw exception. To avoid that, 
NativeHandler::handle could be an empty method instead.

-

PR: https://git.openjdk.org/jdk/pull/9100

Re: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle [v2]

[Peter Levart]

On Fri, 10 Jun 2022 11:45:28 GMT, David M. Lloyd  wrote:

>> Hello David, I suspect you mean `handlers.put(sig, handler)` and not 
>> `handlers.replace(...)`? And yes, I think what you suggest will help remove 
>> the synchronized block here.
>
> Oops, yes you are correct!

Hi,
I think the synchronized block was redundant already in original code. Since 
the entire handle method is `static synchronized` and it is the only method 
that modifies the `handlers` and `signals` maps.
But even with so much redundant synchronization, the Signal class is not 
without races. There are multiple possible races in `dispatch(int number)` 
method which is called from native code to dispatch a signal:
- race no. 1: dispatch method (not synchronized) performs 2 independent lookups 
into `signals` and `handlers` maps respectively, assuming their 
inter-referenced state is consistent. But `handle` method may be concurrently 
modifying them, so `dispatch` may see updated state of `signals` map while 
seeing old state of `handlers` map or vice versa.
- race  no. 2: besides `signals` and `handlers` there is a 3rd map in native 
code, updated with `handle0` native method. Native code dispatches signals 
according to that native map, forwarding them to either native handlers or to 
`dispatch` Java method. But `handle` method may be modifying that native map 
concurrently, so dispatch may be called as a consequence of updated native map 
while seeing old states of `signals` and `handlers` maps.

I'm sure I might have missed some additional races.

How to fix this? Is it even necessary? I think that this internal API is not 
used frequently so this was hardly an issue. But anyway, it would be a 
challenge. While the two java maps: `handlers` and `signals` could be replaced 
with a single map, there is the 3rd map in native code. We would not want to 
make `dispatch` method synchronized, so with careful ordering of modifications 
it is perhaps possible to account for races and make them harmless...
WDYT?

-

PR: https://git.openjdk.org/jdk/pull/9100

Integrated: 8279047: Remove expired flags in JDK 20

[David Holmes]

On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes  wrote:

> Expired Flags in 20:
> 
> - FilterSpuriousWakeups
> - MinInliningThreshold
> - PrefetchFieldsAhead
> 
> No remaining usages in code or tests.
> 
> - UseHeavyMonitors  (expired in PRODUCT ONLY)
> 
> As this flag now only exists for debug builds it has to be a "develop" flag 
> rather than product. There are then changes to two tests that use this flag, 
> so that they only run on a debug VM.
> 
> - test/jdk/java/lang/Thread/virtual/HoldsLock.java
> 
> The second @run that uses UseHeavyMonitors is moved to a second test segment 
> that only applies to the debug VM.
> 
> - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
> 
> Change the test section that uses UseHeavyMonitors to only run on a debug VM 
> and remove the IgnoreUnrecognizedOptions flag. Note that the existing test 
> logic would run the same test twice on product builds.
> 
> No documentation in the manpage exists for any of the newly expired flags.
> 
> Obsoleted flags in 20:
> 
> - ExtendedDTraceProbes
> 
> Documented in manpage so moved from Deprecated section to Obsolete section. 
> There is special handling for messages about use of this flag so that won't 
> be updated until the flag is actually obsoleted (JDK-8279913).
> 
> - UseContainerCpuShares
> - PreferContainerQuotaForCPUCount
> - AliasLevel
> 
> Undocumented.
> 
> Java manpage updates:
> - Updates Java version to 20
> - Moved ExtendedDTraceProbe info as previously mentioned
> - Applied changes from the .1 file that had not been applied to the markdown 
> source so that they were not lost (and note the .1 file was also missing 
> changes from the markdown file that had not been propagated).
> - Removed an unrepresentable character (the section symbol) that was not 
> being generated into either the html or nroff file correctly

This pull request has now been integrated.

Changeset: d46f404b
Author:David Holmes 
URL:   
https://git.openjdk.org/jdk/commit/d46f404b3179c66e8e5775a9e2253c95238153c7
Stats: 69 lines in 5 files changed: 23 ins; 26 del; 20 mod

8279047: Remove expired flags in JDK 20

Reviewed-by: kvn, kbarrett, alanb

-

PR: https://git.openjdk.org/jdk/pull/9127

Re: RFR: 8279047: Remove expired flags in JDK 20

[David Holmes]

On Sat, 11 Jun 2022 05:48:14 GMT, Alan Bateman  wrote:

>> Expired Flags in 20:
>> 
>> - FilterSpuriousWakeups
>> - MinInliningThreshold
>> - PrefetchFieldsAhead
>> 
>> No remaining usages in code or tests.
>> 
>> - UseHeavyMonitors  (expired in PRODUCT ONLY)
>> 
>> As this flag now only exists for debug builds it has to be a "develop" flag 
>> rather than product. There are then changes to two tests that use this flag, 
>> so that they only run on a debug VM.
>> 
>> - test/jdk/java/lang/Thread/virtual/HoldsLock.java
>> 
>> The second @run that uses UseHeavyMonitors is moved to a second test segment 
>> that only applies to the debug VM.
>> 
>> - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
>> 
>> Change the test section that uses UseHeavyMonitors to only run on a debug VM 
>> and remove the IgnoreUnrecognizedOptions flag. Note that the existing test 
>> logic would run the same test twice on product builds.
>> 
>> No documentation in the manpage exists for any of the newly expired flags.
>> 
>> Obsoleted flags in 20:
>> 
>> - ExtendedDTraceProbes
>> 
>> Documented in manpage so moved from Deprecated section to Obsolete section. 
>> There is special handling for messages about use of this flag so that won't 
>> be updated until the flag is actually obsoleted (JDK-8279913).
>> 
>> - UseContainerCpuShares
>> - PreferContainerQuotaForCPUCount
>> - AliasLevel
>> 
>> Undocumented.
>> 
>> Java manpage updates:
>> - Updates Java version to 20
>> - Moved ExtendedDTraceProbe info as previously mentioned
>> - Applied changes from the .1 file that had not been applied to the markdown 
>> source so that they were not lost (and note the .1 file was also missing 
>> changes from the markdown file that had not been propagated).
>> - Removed an unrepresentable character (the section symbol) that was not 
>> being generated into either the html or nroff file correctly
>
> Marked as reviewed by alanb (Reviewer).

Thanks for the review @AlanBateman !

-

PR: https://git.openjdk.org/jdk/pull/9127

Re: RFR: 8279047: Remove expired flags in JDK 20

[Alan Bateman]

On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes  wrote:

> Expired Flags in 20:
> 
> - FilterSpuriousWakeups
> - MinInliningThreshold
> - PrefetchFieldsAhead
> 
> No remaining usages in code or tests.
> 
> - UseHeavyMonitors  (expired in PRODUCT ONLY)
> 
> As this flag now only exists for debug builds it has to be a "develop" flag 
> rather than product. There are then changes to two tests that use this flag, 
> so that they only run on a debug VM.
> 
> - test/jdk/java/lang/Thread/virtual/HoldsLock.java
> 
> The second @run that uses UseHeavyMonitors is moved to a second test segment 
> that only applies to the debug VM.
> 
> - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
> 
> Change the test section that uses UseHeavyMonitors to only run on a debug VM 
> and remove the IgnoreUnrecognizedOptions flag. Note that the existing test 
> logic would run the same test twice on product builds.
> 
> No documentation in the manpage exists for any of the newly expired flags.
> 
> Obsoleted flags in 20:
> 
> - ExtendedDTraceProbes
> 
> Documented in manpage so moved from Deprecated section to Obsolete section. 
> There is special handling for messages about use of this flag so that won't 
> be updated until the flag is actually obsoleted (JDK-8279913).
> 
> - UseContainerCpuShares
> - PreferContainerQuotaForCPUCount
> - AliasLevel
> 
> Undocumented.
> 
> Java manpage updates:
> - Updates Java version to 20
> - Moved ExtendedDTraceProbe info as previously mentioned
> - Applied changes from the .1 file that had not been applied to the markdown 
> source so that they were not lost (and note the .1 file was also missing 
> changes from the markdown file that had not been propagated).
> - Removed an unrepresentable character (the section symbol) that was not 
> being generated into either the html or nroff file correctly

Marked as reviewed by alanb (Reviewer).

test/jdk/java/lang/Thread/virtual/HoldsLock.java line 39:

> 37:  * @modules java.base/java.lang:+open
> 38:  * @compile --enable-preview -source ${jdk.version} HoldsLock.java
> 39:  * @run testng/othervm --enable-preview -XX:+UseHeavyMonitors HoldsLock

The test updates look okay, probably don't need to duplicate the summary tag 
when it's unchanged but what you have is okay.

-

PR: https://git.openjdk.org/jdk/pull/9127

Re: RFR: 8279047: Remove expired flags in JDK 20

[David Holmes]

On Fri, 10 Jun 2022 15:57:40 GMT, Vladimir Kozlov  wrote:

>> Expired Flags in 20:
>> 
>> - FilterSpuriousWakeups
>> - MinInliningThreshold
>> - PrefetchFieldsAhead
>> 
>> No remaining usages in code or tests.
>> 
>> - UseHeavyMonitors  (expired in PRODUCT ONLY)
>> 
>> As this flag now only exists for debug builds it has to be a "develop" flag 
>> rather than product. There are then changes to two tests that use this flag, 
>> so that they only run on a debug VM.
>> 
>> - test/jdk/java/lang/Thread/virtual/HoldsLock.java
>> 
>> The second @run that uses UseHeavyMonitors is moved to a second test segment 
>> that only applies to the debug VM.
>> 
>> - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
>> 
>> Change the test section that uses UseHeavyMonitors to only run on a debug VM 
>> and remove the IgnoreUnrecognizedOptions flag. Note that the existing test 
>> logic would run the same test twice on product builds.
>> 
>> No documentation in the manpage exists for any of the newly expired flags.
>> 
>> Obsoleted flags in 20:
>> 
>> - ExtendedDTraceProbes
>> 
>> Documented in manpage so moved from Deprecated section to Obsolete section. 
>> There is special handling for messages about use of this flag so that won't 
>> be updated until the flag is actually obsoleted (JDK-8279913).
>> 
>> - UseContainerCpuShares
>> - PreferContainerQuotaForCPUCount
>> - AliasLevel
>> 
>> Undocumented.
>> 
>> Java manpage updates:
>> - Updates Java version to 20
>> - Moved ExtendedDTraceProbe info as previously mentioned
>> - Applied changes from the .1 file that had not been applied to the markdown 
>> source so that they were not lost (and note the .1 file was also missing 
>> changes from the markdown file that had not been propagated).
>> - Removed an unrepresentable character (the section symbol) that was not 
>> being generated into either the html or nroff file correctly
>
> Looks good.

Thanks for the reviews @vnkozlov  and @kimbarrett !

-

PR: https://git.openjdk.org/jdk/pull/9127

Integrated: 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html

[Joe Darcy]

On Sat, 11 Jun 2022 00:35:52 GMT, Joe Darcy  wrote:

> 8288173: JDK-8202449 fix causes conformance test failure : 
> api/java_util/Random/RandomGenerator/NextFloat.html

This pull request has now been integrated.

Changeset: f4b05a11
Author:Joe Darcy 
URL:   
https://git.openjdk.org/jdk19/commit/f4b05a1168e17000ef31173860af77aa722d2280
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8288173: JDK-8202449 fix causes conformance test failure : 
api/java_util/Random/RandomGenerator/NextFloat.html

Backport-of: da2339cf6971532593e4f1b5ebbce8d1ed2e83b2

-

PR: https://git.openjdk.org/jdk19/pull/5

Integrated: 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html

[Joe Darcy]

8288173: JDK-8202449 fix causes conformance test failure : 
api/java_util/Random/RandomGenerator/NextFloat.html

-

Commit messages:
 - Backport da2339cf6971532593e4f1b5ebbce8d1ed2e83b2

Changes: https://git.openjdk.org/jdk19/pull/5/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk19=5=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288173
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk19/pull/5.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/5/head:pull/5

PR: https://git.openjdk.org/jdk19/pull/5

Re: RFR: JDK-8288094: cleanup old _MSC_VER handling

[Phil Race]

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken  wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of 
> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't 
> want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see 
> https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4
>  .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also 
> probably older than VS2015) would not be able to build jdk anymore.

src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 38:

> 36: #  define ROUND_TO_INT(num)((int) round(num))
> 37: #else
> 38: #  define ROUND_TO_INT(num)((int) floor((num) + 0.5))

If you look at when and why this was introduced (*), the "else" was not to 
support some other compiler - it was to support the older MS compiler. So if 
you don't want that, then the whole thing reduces to
#define ROUND_TO_INT(num) ((int) round(num))

.. you could even go further and eliminate the macro altogether if it makes 
sense - you'd have to look at the usages.

Same logic applies to the other files.


(*) https://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010889.html

-

PR: https://git.openjdk.org/jdk/pull/9105

RFR: 8287868: Localized names update in COMPAT locale provider

[Naoto Sato]

As the name suggests, `COMPAT` locale provider keeps compatibility with JDK8's 
locale data (before CLDR).  This is useful for legacy applications, but some of 
its data got obsolete for later locale data updates, such as the country name 
change for `Eswatini` (formerly known as `Swaziland`). This PR is to fix those 
names up-to-date from CLDR. More specifically, changes are made for `language`, 
`country`, `script` display names in `Locale` class, and `Currency` display 
names. Localized names used for `TimeZone`s and `Currency` symbols (such as 
`$`) are not modified so that `format`/`parse` should work as with JDK8.

-

Commit messages:
 - 8287868: Localized names update in COMPAT locale provider

Changes: https://git.openjdk.org/jdk/pull/9134/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9134=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287868
  Stats: 9930 lines in 65 files changed: 17 ins; 7 del; 9906 mod
  Patch: https://git.openjdk.org/jdk/pull/9134.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9134/head:pull/9134

PR: https://git.openjdk.org/jdk/pull/9134

Integrated: 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html

[Raffaello Giulietti]

On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti  
wrote:

> This fixes a bug introduced with JDK-8202449.

This pull request has now been integrated.

Changeset: da2339cf
Author:Raffaello Giulietti 
Committer: Brian Burkhalter 
URL:   
https://git.openjdk.org/jdk/commit/da2339cf6971532593e4f1b5ebbce8d1ed2e83b2
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8288173: JDK-8202449 fix causes conformance test failure : 
api/java_util/Random/RandomGenerator/NextFloat.html

Reviewed-by: bpb, darcy

-

PR: https://git.openjdk.org/jdk/pull/9120

Re: RFR: 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html

[Joe Darcy]

On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti  
wrote:

> This fixes a bug introduced with JDK-8202449.

Changes look okay, but please do a follow-up fix to add some regression tests 
for this condition.

-

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9120

Re: RFR: 8279047: Remove expired flags in JDK 20

[Kim Barrett]

On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes  wrote:

> Expired Flags in 20:
> 
> - FilterSpuriousWakeups
> - MinInliningThreshold
> - PrefetchFieldsAhead
> 
> No remaining usages in code or tests.
> 
> - UseHeavyMonitors  (expired in PRODUCT ONLY)
> 
> As this flag now only exists for debug builds it has to be a "develop" flag 
> rather than product. There are then changes to two tests that use this flag, 
> so that they only run on a debug VM.
> 
> - test/jdk/java/lang/Thread/virtual/HoldsLock.java
> 
> The second @run that uses UseHeavyMonitors is moved to a second test segment 
> that only applies to the debug VM.
> 
> - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
> 
> Change the test section that uses UseHeavyMonitors to only run on a debug VM 
> and remove the IgnoreUnrecognizedOptions flag. Note that the existing test 
> logic would run the same test twice on product builds.
> 
> No documentation in the manpage exists for any of the newly expired flags.
> 
> Obsoleted flags in 20:
> 
> - ExtendedDTraceProbes
> 
> Documented in manpage so moved from Deprecated section to Obsolete section. 
> There is special handling for messages about use of this flag so that won't 
> be updated until the flag is actually obsoleted (JDK-8279913).
> 
> - UseContainerCpuShares
> - PreferContainerQuotaForCPUCount
> - AliasLevel
> 
> Undocumented.
> 
> Java manpage updates:
> - Updates Java version to 20
> - Moved ExtendedDTraceProbe info as previously mentioned
> - Applied changes from the .1 file that had not been applied to the markdown 
> source so that they were not lost (and note the .1 file was also missing 
> changes from the markdown file that had not been propagated).
> - Removed an unrepresentable character (the section symbol) that was not 
> being generated into either the html or nroff file correctly

Looks good.

-

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9127

Re: RFR: JDK-8288094: cleanup old _MSC_VER handling

[Christoph Langer]

On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken  wrote:

> We still handle at a number of places ancient historic _MSC_VER versions of 
> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't 
> want to adjust.
> 
> Currently still supported ("valid") VS version are 2017+, see 
> https://github.com/openjdk/jdk/blob/master/make/autoconf/toolchain_microsoft.m4
>  .
> VALID_VS_VERSIONS="2019 2017 2022"
> Even with adjusted toolchain m4 files, something older than VS2013 (also 
> probably older than VS2015) would not be able to build jdk anymore.

Looks good to me.

-

Marked as reviewed by clanger (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9105

Re: RFR: 8288140: Avoid redundant Hashtable.get call in Signal.handle [v2]

[Roger Riggs]

On Fri, 10 Jun 2022 11:31:06 GMT, Andrey Turbanov  wrote:

>> https://github.com/openjdk/jdk/blob/bc28baeba9360991e9b7575e1fbe178d873ccfc1/src/java.base/share/classes/jdk/internal/misc/Signal.java#L177-L178
>> 
>> Instead of separate Hashtable.get/remove calls we can just use value 
>> returned by `remove`,
>> It results in cleaner and a bit faster code.
>
> Andrey Turbanov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8288140: Avoid redundant Hashtable.get call in Signal.handle
>   apply dmlloyd's suggestion

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/jdk/internal/misc/Signal.java line 181:

> 179: } else {
> 180: oldHandler = handlers.remove(sig);
> 181: }

A ternary assignment might be an alternative here:

 Signal.Handler oldHandler = (newH == 2) ? handlers.put(sig, handler) : 
handlers.remove(sig);

-

PR: https://git.openjdk.org/jdk/pull/9100

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat

[Sean Mullan]

On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken  wrote:

> When trying to construct an LdapURL object with a bad input string (in this 
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run 
> into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  
> String url = "ldap://ad_jbs.ttt.net:389/xyz;; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: 
> ldap://ad_jbs.ttt.net:389/xyz [Root exception is 
> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: 
> ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example 
> it is host:port of URI:null:-1] ) so that it is directly visible that the 
> input caused the construction of a URI
> with "special"/problematic host and port values.

I'll take a look from the security side but may need a few days to review and 
possibly collaborate with others if I have concerns.

-

PR: https://git.openjdk.org/jdk/pull/9126

Re: RFR: 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used [v8]

[Alan Bateman]

On Fri, 10 Jun 2022 18:19:42 GMT, Thiago Henrique Hüpner 
 wrote:

>> test/jdk/tools/jar/modularJar/Basic.java line 44:
>> 
>>> 42: 
>>> 43: import jdk.internal.module.ModuleReferenceImpl;
>>> 44: import jdk.internal.module.ModuleResolution;
>> 
>> At some point we need to put in test infrastructure to avoid this and a few 
>> other tests from depending on JDK internals.
>
> Do you think it is better to parse the output of `javap` instead of using the 
> internals to detect if it worked?

Parsing the output of javap would be fragile. Instead, I think we'll just add 
some test infrastructure at some point, maybe when this class file attribute is 
documented somewhere.

-

PR: https://git.openjdk.org/jdk/pull/9049

Re: RFR: 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used [v8]

[Thiago Henrique Hüpner]

On Fri, 10 Jun 2022 18:01:24 GMT, Alan Bateman  wrote:

>> Thiago Henrique Hüpner has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Fix copyright year
>
> test/jdk/tools/jar/modularJar/Basic.java line 44:
> 
>> 42: 
>> 43: import jdk.internal.module.ModuleReferenceImpl;
>> 44: import jdk.internal.module.ModuleResolution;
> 
> At some point we need to put in test infrastructure to avoid this and a few 
> other tests from depending on JDK internals.

Do you think it is better to parse the output of `javap` instead of using the 
internals to detect if it worked?

-

PR: https://git.openjdk.org/jdk/pull/9049

Re: RFR: 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used [v9]

[Alan Bateman]

On Fri, 10 Jun 2022 18:25:09 GMT, Thiago Henrique Hüpner 
 wrote:

>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved 
>> flags is used
>
> Thiago Henrique Hüpner has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Rename dataprovider

Marked as reviewed by alanb (Reviewer).

-

PR: https://git.openjdk.org/jdk/pull/9049

Re: RFR: 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used [v9]

[Thiago Henrique Hüpner]

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved 
> flags is used

Thiago Henrique Hüpner has updated the pull request incrementally with one 
additional commit since the last revision:

  Rename dataprovider

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/9049/files
  - new: https://git.openjdk.org/jdk/pull/9049/files/962f0ec1..d566ebca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=9049=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9049=07-08

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9049.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9049/head:pull/9049

PR: https://git.openjdk.org/jdk/pull/9049

Re: RFR: 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html

[Brian Burkhalter]

On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti  
wrote:

> This fixes a bug introduced with JDK-8202449.

Marked as reviewed by bpb (Reviewer).

-

PR: https://git.openjdk.org/jdk/pull/9120

Re: RFR: 8288173: JDK-8202449 fix causes conformance test failure : api/java_util/Random/RandomGenerator/NextFloat.html

[Raffaello Giulietti]

On Fri, 10 Jun 2022 08:36:57 GMT, Raffaello Giulietti  
wrote:

> This fixes a bug introduced with JDK-8202449.

The fix reverts an inadvertent "correction" sneaked into JDK-8202449, restoring 
previous (correct) behavior.

-

PR: https://git.openjdk.org/jdk/pull/9120

Re: RFR: 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used [v8]

[Alan Bateman]

On Fri, 10 Jun 2022 16:30:57 GMT, Thiago Henrique Hüpner 
 wrote:

>> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved 
>> flags is used
>
> Thiago Henrique Hüpner has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Fix copyright year

test/jdk/tools/jar/modularJar/Basic.java line 44:

> 42: 
> 43: import jdk.internal.module.ModuleReferenceImpl;
> 44: import jdk.internal.module.ModuleResolution;

At some point we need to put in test infrastructure to avoid this and a few 
other tests from depending on JDK internals.

test/jdk/tools/jar/modularJar/Basic.java line 951:

> 949: 
> 950: @DataProvider(name = "resolutionNames")
> 951: public Object[][] resolutionNames() {

This is a data provider for resolution warnings, maybe it should be renamed.

-

PR: https://git.openjdk.org/jdk/pull/9049

Re: RFR: 8287917: System.loadLibrary does not work on Big Sur if JDK is built with macOS SDK 10.15 and earlier

[Mandy Chung]

On Wed, 8 Jun 2022 04:59:07 GMT, Yoshiki Sato  wrote:

> Please review this PR.
> SDK 10.15 and earlier reports os.version as 10.16 on Big Sur.  This fix will 
> check if dynamic linker support, which is supported from Big Sur, is 
> available or not on the OS even if os.version is reported as 10.16 instead of 
> 11.  The os.version 10.16 doesn't include the update version like y of 
> 10.x.y.  Hence the change only see if it is 10.16 or not.

Looks good.  Thanks for fixing this.

As a background, Big Sur reports 10.16 as backward compatibility when built 
with macOS SDK 10.15 and earlier.   Hence this needs to check for os version 
10.16 that supports dynamic linker cache.

test/jdk/java/lang/RuntimeTests/loadLibrary/exeLibraryCache/LibraryFromCache.java
 line 45:

> 43: public class LibraryFromCache {
> 44: public static void main(String[] args) throws IOException {
> 45: System.out.println("os.version = " + 
> System.getProperty("os.version"));

The copyright end year needs to be updated.

-

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9077

Integrated: JDK-8288227: Refactor annotation implementation to use pattern matching for instanceof

[Joe Darcy]

On Fri, 10 Jun 2022 16:15:36 GMT, Joe Darcy  wrote:

> There are many instanceof checks in the sun.reflection.annotation code; these 
> would be improved by using pattern matching for instanceof.

This pull request has now been integrated.

Changeset: aaa89714
Author:Joe Darcy 
URL:   
https://git.openjdk.org/jdk/commit/aaa897148ab2669e06531521221f0551335b3d1f
Stats: 57 lines in 4 files changed: 1 ins; 14 del; 42 mod

8288227: Refactor annotation implementation to use pattern matching for 
instanceof

Reviewed-by: alanb

-

PR: https://git.openjdk.org/jdk/pull/9129

Re: RFR: JDK-8288227: Refactor annotation implementation to use pattern matching for instanceof

[Alan Bateman]

On Fri, 10 Jun 2022 16:15:36 GMT, Joe Darcy  wrote:

> There are many instanceof checks in the sun.reflection.annotation code; these 
> would be improved by using pattern matching for instanceof.

Marked as reviewed by alanb (Reviewer).

-

PR: https://git.openjdk.org/jdk/pull/9129

Re: RFR: JDK-8288227: Refactor annotation implementation to use pattern matching for instanceof

[Raffaello Giulietti]

On Fri, 10 Jun 2022 16:15:36 GMT, Joe Darcy  wrote:

> There are many instanceof checks in the sun.reflection.annotation code; these 
> would be improved by using pattern matching for instanceof.

Seems clean

-

PR: https://git.openjdk.org/jdk/pull/9129

Re: RFR: 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved flags is used [v8]

[Thiago Henrique Hüpner]

> 8287760: --do-not-resolve-by-default gets overwritten if --warn-if-resolved 
> flags is used

Thiago Henrique Hüpner has updated the pull request incrementally with one 
additional commit since the last revision:

  Fix copyright year

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/9049/files
  - new: https://git.openjdk.org/jdk/pull/9049/files/8544abd9..962f0ec1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=9049=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=9049=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9049.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9049/head:pull/9049

PR: https://git.openjdk.org/jdk/pull/9049

RFR: JDK-8288227: Refactor annotation implementation to use pattern matching for instanceof

[Joe Darcy]

There are many instanceof checks in the sun.reflection.annotation code; these 
would be improved by using pattern matching for instanceof.

-

Commit messages:
 - JDK-8288227: Refactor annotation implementation to use pattern matching for 
instanceo

Changes: https://git.openjdk.org/jdk/pull/9129/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9129=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288227
  Stats: 57 lines in 4 files changed: 1 ins; 14 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/9129.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9129/head:pull/9129

PR: https://git.openjdk.org/jdk/pull/9129

Re: RFR: 8279047: Remove expired flags in JDK 20

[Vladimir Kozlov]

On Fri, 10 Jun 2022 13:23:51 GMT, David Holmes  wrote:

> Expired Flags in 20:
> 
> - FilterSpuriousWakeups
> - MinInliningThreshold
> - PrefetchFieldsAhead
> 
> No remaining usages in code or tests.
> 
> - UseHeavyMonitors  (expired in PRODUCT ONLY)
> 
> As this flag now only exists for debug builds it has to be a "develop" flag 
> rather than product. There are then changes to two tests that use this flag, 
> so that they only run on a debug VM.
> 
> - test/jdk/java/lang/Thread/virtual/HoldsLock.java
> 
> The second @run that uses UseHeavyMonitors is moved to a second test segment 
> that only applies to the debug VM.
> 
> - test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java
> 
> Change the test section that uses UseHeavyMonitors to only run on a debug VM 
> and remove the IgnoreUnrecognizedOptions flag. Note that the existing test 
> logic would run the same test twice on product builds.
> 
> No documentation in the manpage exists for any of the newly expired flags.
> 
> Obsoleted flags in 20:
> 
> - ExtendedDTraceProbes
> 
> Documented in manpage so moved from Deprecated section to Obsolete section. 
> There is special handling for messages about use of this flag so that won't 
> be updated until the flag is actually obsoleted (JDK-8279913).
> 
> - UseContainerCpuShares
> - PreferContainerQuotaForCPUCount
> - AliasLevel
> 
> Undocumented.
> 
> Java manpage updates:
> - Updates Java version to 20
> - Moved ExtendedDTraceProbe info as previously mentioned
> - Applied changes from the .1 file that had not been applied to the markdown 
> source so that they were not lost (and note the .1 file was also missing 
> changes from the markdown file that had not been propagated).
> - Removed an unrepresentable character (the section symbol) that was not 
> being generated into either the html or nroff file correctly

Looks good.

-

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9127

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat

[Daniel Fuchs]

On Fri, 10 Jun 2022 12:16:17 GMT, Matthias Baesken  wrote:

> When trying to construct an LdapURL object with a bad input string (in this 
> example the _ in ad_jbs is causing issues), and not using
> the backward compatibility flag -Dcom.sun.jndi.ldapURLParsing="legacy" we run 
> into the exception below :
> 
> import com.sun.jndi.ldap.LdapURL;
>  
> String url = "ldap://ad_jbs.ttt.net:389/xyz;; // bad input string containing _
> LdapURL ldapUrl = new LdapURL(url);
> 
> 
> java --add-opens java.naming/com.sun.jndi.ldap=ALL-UNNAMED LdapParseUrlTest
> Exception in thread "main" javax.naming.NamingException: Cannot parse url: 
> ldap://ad_jbs.ttt.net:389/xyz [Root exception is 
> java.net.MalformedURLException: unsupported authority: ad_jbs.ttt.net:389]
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:115)
> at LdapParseUrlTest.main(LdapParseUrlTest.java:9)
> Caused by: java.net.MalformedURLException: unsupported authority: 
> ad_jbs.ttt.net:389
> at java.naming/com.sun.jndi.toolkit.url.Uri.parseCompat(Uri.java:367)
> at java.naming/com.sun.jndi.toolkit.url.Uri.parse(Uri.java:230)
> at java.naming/com.sun.jndi.toolkit.url.Uri.init(Uri.java:174)
> at java.naming/com.sun.jndi.ldap.LdapURL.(LdapURL.java:105)
> 
> I would like to add the host and port info to the exception (in the example 
> it is host:port of URI:null:-1] ) so that it is directly visible that the 
> input caused the construction of a URI
> with "special"/problematic host and port values.

`URISyntaxException`/`MalformedURLException` usually contains the whole URL - 
so in this case, because we're parsing a URL, I believe the added information 
would not leak more sensitive data - especially since I'd expect URI.getHost() 
to be always `null` and `URI.getPort()` to be always `-1` in this case. 
That is - this exception is thrown when the authority is parsed as a reg_name, 
as opposed to server-base, because the provided host name (or what looks like a 
host name) contains a character that is not allowed by java.net.URI in a host 
name.


jshell> URI.create("ldap://a_b.com:389/foo;);
$1 ==> ldap://a_b.com:389/foo

jshell> $1.getAuthority()
$2 ==> "a_b.com:389"

jshell> $1.getHost()
$3 ==> null


As a point of comparison, here is what URISyntaxException looks like if the 
authority contains a character which is not legal at all in authority:


jshell> new URI("ldap://a_%b.com:389/foo;);
|  Exception java.net.URISyntaxException: Malformed escape pair at index 9: 
ldap://a_%b.com:389/foo
|at URI$Parser.fail (URI.java:2973)


I agree we should wait for someone from security-dev to chime in though.

I might question whether the added "null:-1" information is really helpful, or 
just as confusing however.

-

PR: https://git.openjdk.org/jdk/pull/9126

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat

[Alan Bateman]

On Fri, 10 Jun 2022 13:41:48 GMT, Matthias Baesken  wrote:

> Hi Alan , sure we could use something like the already existing hostInfo of 
> property jdk.includeInException private static final boolean 
> enhancedExceptionText = SecurityProperties.includedInExceptions("hostInfo"); 
> and make the enhancement optional/switchable this way. On the other hand we 
> already print the url (_**Cannot parse url: ldap://ad_jbs.ttt.net:389/xyz**_ 
> ) in the existing exception text so I wonder what additional problem the 
> added info would bring? That's why I did not use the property so far. But if 
> you think there could be special cases were it would be problematic to have 
> the enhancement, I'll add the usage of the property.

This is a security sensitive area and not possible to discuss all issues in JBS 
or in this PR. If this code is changed then it will require someone from 
security-dev to review.

-

PR: https://git.openjdk.org/jdk/pull/9126

Re: RFR: JDK-8288207: Enhance MalformedURLException in Uri.parseCompat

[Matthias Baesken]

On Fri, 10 Jun 2022 13:15:11 GMT, Alan Bateman  wrote:

> We have to be cautious about leaking security sensitive configuration in 
> exception messages. Can you look at the security property 
> jdk.includeInException (conf/security/java.security) and usages in the JDK 
> for ideas on how this might be implemented as opt-in?

Hi Alan ,   sure we could use something like the already existing hostInfo of 
property jdk.includeInException 
  private static final boolean enhancedExceptionText = 
SecurityProperties.includedInExceptions("hostInfo");
and make the enhancement optional/switchable this way.
On the other hand we already print the url  (_**Cannot parse url: 
ldap://ad_jbs.ttt.net:389/xyz**_ )  in the existing exception text so I wonder 
what additional problem the added info would bring? That's why I  did not use 
the property so far.
But if you think there could be special cases were it would be problematic to 
have the enhancement, I'll add the usage of the property.

-

PR: https://git.openjdk.org/jdk/pull/9126

RFR: 8279047: Remove expired flags in JDK 20

[David Holmes]

Expired Flags in 20:

- FilterSpuriousWakeups
- MinInliningThreshold
- PrefetchFieldsAhead

No remaining usages in code or tests.

- UseHeavyMonitors  (expired in PRODUCT ONLY)

As this flag now only exists for debug builds it has to be a "develop" flag 
rather than product. There are then changes to two tests that use this flag, so 
that they only run on a debug VM.

- test/jdk/java/lang/Thread/virtual/HoldsLock.java

The second @run that uses UseHeavyMonitors is moved to a second test segment 
that only applies to the debug VM.

- test/jdk/java/util/concurrent/ConcurrentHashMap/MapLoops.java

Change the test section that uses UseHeavyMonitors to only run on a debug VM 
and remove the IgnoreUnrecognizedOptions flag. Note that the existing test 
logic would run the same test twice on product builds.

No documentation in the manpage exists for any of the newly expired flags.

Obsoleted flags in 20:

- ExtendedDTraceProbes

Documented in manpage so moved from Deprecated section to Obsolete section. 
There is special handling for messages about use of this flag so that won't be 
updated until the flag is actually obsoleted (JDK-8279913).

- UseContainerCpuShares
- PreferContainerQuotaForCPUCount
- AliasLevel

Undocumented.

Java manpage updates:
- Updates Java version to 20
- Moved ExtendedDTraceProbe info as previously mentioned
- Applied changes from the .1 file that had not been applied to the markdown 
source so that they were not lost (and note the .1 file was also missing 
changes from the markdown file that had not been propagated).
- Removed an unrepresentable character (the section symbol) that was not being 
generated into either the html or nroff file correctly

-

Commit messages:
 - Fix typo
 - 8279047: Remove expired flags in JDK 20

Changes: https://git.openjdk.org/jdk/pull/9127/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=9127=00
  Issue: https://bugs.openjdk.org/browse/JDK-8279047
  Stats: 69 lines in 5 files changed: 23 ins; 26 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/9127.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9127/head:pull/9127

PR: https://git.openjdk.org/jdk/pull/9127