Re: RFR: JDK-8274840: Update OS detection code to recognize Windows 11
On Thu, 7 Oct 2021 11:20:57 GMT, Matthias Baesken wrote: > The OS detection code of the JDK/JVM should recognize the new Windows 11. For > details see : > > https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information > OS build number is : 22000.194 for 21H2 (original release) > > Please review the following small patch ! > (patch comes originally from azeller (Arno Zeller) , I just added a comment > and did some testing) > > Thanks, Matthias Hi Christoph and David, thanks for the reviews ! Best regards, Matthias - PR: https://git.openjdk.java.net/jdk/pull/5846
Integrated: JDK-8274840: Update OS detection code to recognize Windows 11
On Thu, 7 Oct 2021 11:20:57 GMT, Matthias Baesken wrote: > The OS detection code of the JDK/JVM should recognize the new Windows 11. For > details see : > > https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information > OS build number is : 22000.194 for 21H2 (original release) > > Please review the following small patch ! > (patch comes originally from azeller (Arno Zeller) , I just added a comment > and did some testing) > > Thanks, Matthias This pull request has now been integrated. Changeset: 97ea9dd2 Author:Matthias Baesken URL: https://git.openjdk.java.net/jdk/commit/97ea9dd2f24f9f1fb9b9345a4202a825ee28e014 Stats: 15 lines in 2 files changed: 13 ins; 0 del; 2 mod 8274840: Update OS detection code to recognize Windows 11 Co-authored-by: Arno Zeller Reviewed-by: clanger, dholmes - PR: https://git.openjdk.java.net/jdk/pull/5846
Re: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries
On Wed, 2 Jun 2021 20:13:34 GMT, Maurizio Cimadamore
wrote:
>> This patch overhauls the library loading mechanism used by the Foreign
>> Linker API. We realized that, while handy, the *default* lookup abstraction
>> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>>
>> This patch replaces `LibraryLookup` with a simpler `SymbolLookup`
>> abstraction, a functional interface. Crucially, `SymbolLookup` does not
>> concern with library loading, only symbol lookup. For this reason, two
>> factories are added:
>>
>> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to
>> lookup symbols in libraries loaded by current loader
>> * `CLinker::systemLookup` - a more stable replacement for the *default*
>> lookup, which looks for symbols in libc.so (or its equivalent in other
>> platforms). The contents of this lookup are unspecified.
>>
>> Both factories are *restricted*, so they can only be called when
>> `--enable-native-access` is set.
>
>> _Mailing list message from [Chapman Flack](mailto:c...@anastigmatix.net) on
>> [security-dev](mailto:security-...@mail.openjdk.java.net):_
>>
>> On 06/02/21 13:30, Maurizio Cimadamore wrote:
>>
>> > This patch replaces `LibraryLookup` with a simpler `SymbolLookup`
>> > abstraction, a functional interface. Crucially, `SymbolLookup` does not
>> > concern with library loading, only symbol lookup. For this reason, two
>> > factories are added:
>>
>> Hi,
>>
>> While I am thinking about this, what will be the behavior when the JVM
>> itself has been dynamically loaded into an embedding application, and
>> launched with the JNI invocation API?
>>
>> Will there be a *Lookup flavor that is able to find any exported symbol
>> known in the embedding environment the JVM was loaded into? (This is the
>> sort of condition the Mac OS linker checks when given the -bundle_loader
>> option.)
>>
>> Regards,
>> Chapman Flack (maintainer of a project that happens to work that way)
>
> Hi,
> at the moment we don't have plans to add such a lookup, but I believe it
> should be possible to build such a lookup using `dlopen` and the linker API.
> I have provided an example elsewhere of how easy it easy to build a wrapper
> lookup around dlopen/dlsym:
>
> https://gist.github.com/mcimadamore/0883ea6f4836ae0c1d2a31c48197da1a
>
> Perhaps something like that could be useful in the use case you mention?
Hi @mcimadamore,
As you mentioned at
https://github.com/openjdk/jdk/pull/4316#issuecomment-853238872, the system
lookup is supported by the underlying `NativeLibraries` which also works on
OpenJDK16 to support `LibraryLookup::ofDefault`.
But my finding is that it `LibraryLookup::ofDefault` works good on AIX (with
`libc.a`) in OpenJDK16 but `CLinker.systemLookup()` ended up with
`NoSuchElementException` after changing the code in `SystemLookup.java` and
`CABI.java` as follows:
private static final SymbolLookup syslookup = switch (CABI.current()) {
case SysV, LinuxAArch64, MacOsAArch64, AIX -> libLookup(libs ->
libs.loadLibrary("syslookup"));
case Win64 -> makeWindowsLookup(); // out of line to workaround javac
crash
};
with a simple test & output:
import jdk.incubator.foreign.CLinker;
import static jdk.incubator.foreign.CLinker.*;
import jdk.incubator.foreign.SymbolLookup;
import jdk.incubator.foreign.Addressable;
public class Test {
private static CLinker clinker = CLinker.getInstance();
private static final SymbolLookup defaultLibLookup =
CLinker.systemLookup();
public static void main(String args[]) throws Throwable {
Addressable strlenSymbol =
defaultLibLookup.lookup("strlen").get();
}
}
bin/java --enable-native-access=ALL-UNNAMED --add-modules
jdk.incubator.foreign -Dforeign.restricted=permit Test
WARNING: Using incubator modules: jdk.incubator.foreign
Exception in thread "main" java.util.NoSuchElementException: No value present
<-
at java.base/java.util.Optional.get(Optional.java:143)
at Test.main(Test.java:11)
So I am wondering what happened to the system lookup in such case given there
should be no fundamental difference in leveraging `NativeLibraries` (I assume
the library loading in OpenJDK16 & 17 is the same at this point) unless there
is something else new in OpenJDK17 I am unaware of (e.g. the changes in
`Lib.gmk` or `lib-std.m4`, or a custom system lookup is required on AIX, etc).
Thanks.
-
PR: https://git.openjdk.java.net/jdk/pull/4316
Re: Throwable not thrown. In sun.reflect.generics.parser.SignatureParser#parseBounds
On 8/10/2021 6:10 am, Andrey Turbanov wrote:
Hello.
I found suspicious code in the method
sun.reflect.generics.parser.SignatureParser#parseBounds
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/reflect/generics/parser/SignatureParser.java#L532
Method 'error' called without 'throw'. And the returned value is just ignored.
error("Bound expected");
Current method implementation creates and returns GenericSignatureFormatError.
private Error error(String errorMsg) {
return new GenericSignatureFormatError("Signature Parse error: " +
errorMsg +
"\n\tRemaining input: " +
remainder());
}
I believe it's supposed to be thrown:
throw error("Bound expected");
Or given the comment on error():
// Currently throws a GenericSignatureFormatError.
perhaps the intent was for error() to actually do the throwing.
Obviously missing test coverage here too.
Cheers,
David
Andrey Turbanov
Re: ideas about making static shared pool for skip buffers for InputStream and Reader
each for each class... byte[] and char[] of course cannot mix...at least, cannt mix from java side. I'm not that sure if such black magic can do on jvm side. I don't think it can. It is not safe to open the containing pool to another class either... java have no friend-class system like cpp Brian Burkhalter 于2021年10月8日周五 上午5:37写道： > Re-directing to the appropriate mailing list, core-libs-dev; please > exclude jdk-dev from any reply. > > How can they be shared when they are different data types, viz., byte vs. > char? > > On Oct 7, 2021, at 2:26 PM, Xeno Amess wrote: > > I just wonder, if it worthy to create static shared pools for skip buffers > for InputStream and Reader, instead of create one for each instance. > > I do think it worthy a try. > > pr at https://github.com/openjdk/jdk/pull/5855 > > What the next step should I do? > > >
Re: RFR: 8274864: Remove Amman/Cairo hacks in ZoneInfoFile
On Thu, 7 Oct 2021 21:30:22 GMT, Naoto Sato wrote: > While working on tzdata2021c update, I noticed there is a dead code in > `sun.util.calendar.ZoneInfoFile`, which was used to tweak the rules for > `endOfDay` for certain cases. These are no longer needed as JDK's code is > already capable of dealing with transitions beyond the end of the day. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/5857
Re: ideas about making static shared pool for skip buffers for InputStream and Reader
each for each class... byte[] and char[] of course cannot mix...at least, cannt mix from java side. I'm not that sure if such black magic can do on jvm side. I don't think it can. It is not safe to open the containing pool to another class either... java have no friend-class system like cpp Xeno Amess 于 2021年10月8日周五 上午5:45写道： > each for each class... > > byte[] and char[] of course cannot mix...at least, cannt mix from java > side. I'm not that sure if such black magic can do on jvm side. I don't > think it can. > > It is not safe to open the containing pool to another class either... java > have no friend-class system like cpp > > > Brian Burkhalter 于2021年10月8日周五 上午5:37写道： > >> Re-directing to the appropriate mailing list, core-libs-dev; please >> exclude jdk-dev from any reply. >> >> How can they be shared when they are different data types, viz., byte vs. >> char? >> >> On Oct 7, 2021, at 2:26 PM, Xeno Amess wrote: >> >> I just wonder, if it worthy to create static shared pools for skip buffers >> for InputStream and Reader, instead of create one for each instance. >> >> I do think it worthy a try. >> >> pr at https://github.com/openjdk/jdk/pull/5855 >> >> What the next step should I do? >> >> >>
Re: RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string
On Thu, 7 Oct 2021 21:46:47 GMT, Alex Menkov wrote: > The fix adds "-XX:PerfMaxStringConstLength" argument running target app > (default is 1024, 8K should be enough for any environments) LGTM. Thanks, Serguei - Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5858
RFR: JDK-8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string
The fix adds "-XX:PerfMaxStringConstLength" argument running target app (default is 1024, 8K should be enough for any environments) - Commit messages: - JDK-8274930 Changes: https://git.openjdk.java.net/jdk/pull/5858/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5858&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274930 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5858.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5858/head:pull/5858 PR: https://git.openjdk.java.net/jdk/pull/5858
Re: ideas about making static shared pool for skip buffers for InputStream and Reader
Re-directing to the appropriate mailing list, core-libs-dev; please exclude jdk-dev from any reply. How can they be shared when they are different data types, viz., byte vs. char? On Oct 7, 2021, at 2:26 PM, Xeno Amess mailto:xenoam...@gmail.com>> wrote: I just wonder, if it worthy to create static shared pools for skip buffers for InputStream and Reader, instead of create one for each instance. I do think it worthy a try. pr at https://github.com/openjdk/jdk/pull/5855 What the next step should I do?
RFR: 8274864: Remove Amman/Cairo hacks in ZoneInfoFile
While working on tzdata2021c update, I noticed there is a dead code in `sun.util.calendar.ZoneInfoFile`, which was used to tweak the rules for `endOfDay` for certain cases. These are no longer needed as JDK's code is already capable of dealing with transitions beyond the end of the day. - Commit messages: - 8274864: Remove Amman/Cairo hacks in ZoneInfoFile Changes: https://git.openjdk.java.net/jdk/pull/5857/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5857&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274864 Stats: 29 lines in 1 file changed: 0 ins; 29 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5857.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5857/head:pull/5857 PR: https://git.openjdk.java.net/jdk/pull/5857
Throwable not thrown. In sun.reflect.generics.parser.SignatureParser#parseBounds
Hello.
I found suspicious code in the method
sun.reflect.generics.parser.SignatureParser#parseBounds
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/reflect/generics/parser/SignatureParser.java#L532
Method 'error' called without 'throw'. And the returned value is just ignored.
error("Bound expected");
Current method implementation creates and returns GenericSignatureFormatError.
private Error error(String errorMsg) {
return new GenericSignatureFormatError("Signature Parse error: " +
errorMsg +
"\n\tRemaining input: " +
remainder());
}
I believe it's supposed to be thrown:
throw error("Bound expected");
Andrey Turbanov
Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v6]
On Wed, 6 Oct 2021 21:21:29 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on >> int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single >> element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > Added more comments LSD (Least Significant Digit) Radix sort is introduced to improve sorting. Thшs algorithm requires additional buffer, but has O(n) complexity. At the same time Quicksort performs at O(n*ln(n)). Radix sort shows extremely better performance on large random data, whereas Quicksort or merging sort win on other inputs. We reuse additional buffer, if it is created during merge sort (in case of parallel sorting on computer with many processors). The same approach is used during allocation of buffer in merging sort. So, additional buffer is not created twice. We also check if we have enough memory for the buffer. Otherwise, sorting is continued with in-place algorithms only. Summary: introduced Radix sort requires the same amount memory as merge or merging sorts, reuses it if necessary, but works much faster than Quicksort. - PR: https://git.openjdk.java.net/jdk/pull/3938
Re: RFR: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes
On Thu, 9 Sep 2021 06:50:21 GMT, Andrey Turbanov
wrote:
> StringBuffer is a legacy synchronized class. There are more modern
> alternatives which perform better:
> 1. Plain String concatenation should be preferred
> 2. StringBuilder is a direct replacement to StringBuffer which generally have
> better performance
>
> In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) I
> migrated only usages which were automatically detected by IDEA. It turns out
> there are more usages which can be migrated.
src/java.base/share/classes/java/lang/Character.java line 123:
> 121: * than U+ are called supplementary characters. The Java
> 122: * platform uses the UTF-16 representation in {@code char} arrays and
> 123: * in the {@code String} and {@code StringBuilder} classes. In
Not sure simple replacement applies here, as `StringBuffer` still uses `UTF-16`
representation. You may add `StringBuilder` as well here, but I think you might
want to file a CSR to clarify.
-
PR: https://git.openjdk.java.net/jdk/pull/5432
Integrated: 8274407: (tz) Update Timezone Data to 2021c
On Wed, 6 Oct 2021 01:24:49 GMT, Naoto Sato wrote: > This PR is to upgrade the time zone data in the JDK to IANA's tzdata2021c > level. Note that the tz data is "as is", as released by IANA. No `merged > links` are retracted. > The PR also fixes two issues along with the 2021c upgrade. This pull request has now been integrated. Changeset: 8ca08461 Author:Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/8ca084617f331b6af934179f3f776c8158da5bba Stats: 635 lines in 13 files changed: 228 ins; 329 del; 78 mod 8274407: (tz) Update Timezone Data to 2021c 8274467: TestZoneInfo310.java fails with tzdata2021b 8274468: TimeZoneTest.java fails with tzdata2021b Reviewed-by: rriggs, iris, coffeys - PR: https://git.openjdk.java.net/jdk/pull/5832
RFR: 8271737: Only normalize the cached user.dir property once
The change completes the fix of [JDK-8198997](https://bugs.openjdk.java.net/browse/JDK-8198997) which has added normalisation in a constructor but not removed it from the get method. - Commit messages: - 8271737: Only normalize the cached user.dir property once Changes: https://git.openjdk.java.net/jdk/pull/5850/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5850&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271737 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/5850.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5850/head:pull/5850 PR: https://git.openjdk.java.net/jdk/pull/5850
Re: RFR: JDK-8274840: Update OS detection code to recognize Windows 11
On Thu, 7 Oct 2021 11:20:57 GMT, Matthias Baesken wrote:
> The OS detection code of the JDK/JVM should recognize the new Windows 11. For
> details see :
>
> https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information
> OS build number is : 22000.194 for 21H2 (original release)
>
> Please review the following small patch !
> (patch comes originally from azeller (Arno Zeller) , I just added a comment
> and did some testing)
>
> Thanks, Matthias
Functionally seems fine. One nit about comments.
Thanks,
David
src/java.base/windows/native/libjava/java_props_md.c line 550:
> 548: switch (minorVersion) {
> 549: case 0:
> 550: /* Windows 11 21H2 (original release) build
> number is 22000 */
Given the big comment block before the switch I don't see the need to repeat
the information here. Same goes for the existing comments below for the server
versions.
-
Marked as reviewed by dholmes (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/5846
Re: RFR: 8244202: Implementation of JEP 418: Internet-Address Resolution SPI [v2]
> This change implements a new service provider interface for host name and > address resolution, so that java.net.InetAddress API can make use of > resolvers other than the platform's built-in resolver. > > The following API classes are added to `java.net.spi` package to facilitate > this: > - `InetAddressResolverProvider` - abstract class defining a service, and is, > essentially, a factory for `InetAddressResolver` resolvers. > - `InetAddressResolverProvider.Configuration ` - an interface describing the > platform's built-in configuration for resolution operations that could be > used to bootstrap a resolver construction, or to implement partial delegation > of lookup operations. > - `InetAddressResolver` - an interface that defines methods for the > fundamental forward and reverse lookup operations. > - `InetAddressResolver.LookupPolicy` - a class whose instances describe the > characteristics of one forward lookup operation. > > More details in [JEP-418](https://openjdk.java.net/jeps/418). > > Testing: new and existing `tier1:tier3` tests Aleksei Efimov 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 two additional commits since the last revision: - Merge branch 'master' into JDK-8244202_JEP418_impl - 8244202: Implementation of JEP 418: Internet-Address Resolution SPI - Changes: - all: https://git.openjdk.java.net/jdk/pull/5822/files - new: https://git.openjdk.java.net/jdk/pull/5822/files/77551538..41717fc7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5822&range=00-01 Stats: 4216 lines in 179 files changed: 1929 ins; 1744 del; 543 mod Patch: https://git.openjdk.java.net/jdk/pull/5822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5822/head:pull/5822 PR: https://git.openjdk.java.net/jdk/pull/5822
Re: RFR: JDK-8274840: Update OS detection code to recognize Windows 11
On Thu, 7 Oct 2021 11:20:57 GMT, Matthias Baesken wrote: > The OS detection code of the JDK/JVM should recognize the new Windows 11. For > details see : > > https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information > OS build number is : 22000.194 for 21H2 (original release) > > Please review the following small patch ! > (patch comes originally from azeller (Arno Zeller) , I just added a comment > and did some testing) > > Thanks, Matthias Looks good to me. - Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5846
RFR: JDK-8274840: Update OS detection code to recognize Windows 11
The OS detection code of the JDK/JVM should recognize the new Windows 11. For details see : https://docs.microsoft.com/en-us/windows/release-health/windows11-release-information OS build number is : 22000.194 for 21H2 (original release) Please review the following small patch ! (patch comes originally from azeller (Arno Zeller) , I just added a comment and did some testing) Thanks, Matthias - Commit messages: - JDK-8274840 Changes: https://git.openjdk.java.net/jdk/pull/5846/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5846&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274840 Stats: 15 lines in 2 files changed: 13 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/5846.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5846/head:pull/5846 PR: https://git.openjdk.java.net/jdk/pull/5846
RFR: 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes
StringBuffer is a legacy synchronized class. There are more modern alternatives which perform better: 1. Plain String concatenation should be preferred 2. StringBuilder is a direct replacement to StringBuffer which generally have better performance In [JDK-8264029](https://bugs.openjdk.java.net/browse/JDK-8264029) I migrated only usages which were automatically detected by IDEA. It turns out there are more usages which can be migrated. - Commit messages: - [PATCH] Cleanup usages of StringBuffer in java.base module - [PATCH] Cleanup usages of StringBuffer in java.base module Changes: https://git.openjdk.java.net/jdk/pull/5432/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5432&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8274879 Stats: 32 lines in 12 files changed: 0 ins; 0 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/5432.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5432/head:pull/5432 PR: https://git.openjdk.java.net/jdk/pull/5432
