Re: RFR: 8287971: Throw exception for missing values in .jpackage.xml
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
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
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]
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
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
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
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
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?]
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
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]
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]
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]
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]
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]
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
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]
> 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
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]
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]
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]
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]
> 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
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
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]
> 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
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
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]
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]
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
