On Tue, 8 Jun 2021 16:45:12 GMT, Henry Jen wrote:
>> src/java.base/unix/native/libjli/java_md.c line 666:
>>
>>> 664: return page_size * pages;
>>> 665: }
>>> 666: }
>>
>> Could probably be shortened to something like this:
>>
>>
>> size_t pagesize =
> 8267630: Start of release updates for JDK 18
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The pull request now contains 19 commits:
- Merge branch 'master' into 8267630
- Merge branch 'master' into 8267630
- Merge branch 'master' into 8267630
-
On Tue, 8 Jun 2021 17:58:43 GMT, Joe Darcy wrote:
>> 8267630: Start of release updates for JDK 18
>
> 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
On Tue, 8 Jun 2021 16:53:38 GMT, Henry Jen wrote:
>> …d on macOS
>>
>> This patch simply round up the specified stack size to multiple of the
>> system page size.
>>
>> Test is trivial, simply run java with -Xss option against following code. On
>> MacOS, before the fix, running with
On 8/06/2021 11:40 pm, Thomas Stuefe wrote:
On Mon, 7 Jun 2021 03:18:32 GMT, Henry Jen wrote:
…d on macOS
This patch simply round up the specified stack size to multiple of the system
page size.
Test is trivial, simply run java with -Xss option against following code. On
MacOS, before the
On Tue, 8 Jun 2021 00:30:38 GMT, Scott Gibbons
wrote:
>> Add the Base64 Decode intrinsic for x86 to utilize AVX-512 for acceleration.
>> Also allows for performance improvement for non-AVX-512 enabled platforms.
>> Due to the nature of MIME-encoded inputs, modify the intrinsic signature to
On Wed, 9 Jun 2021 00:42:35 GMT, ScientificWare
wrote:
>> This concerns [dtdbuilder
>> tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder).
>>
>> In jshell, try `System.getProperty("html32") + ""` you'll get a `String`.
>>
>> So, in
On Tue, 8 Jun 2021 12:37:27 GMT, Erik Joelsson wrote:
>> ScientificWare has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Changes to keep home_dtd null check.
>>
>> As suggested in conversation moving `+ File.separator` is more
> This concerns [dtdbuilder
> tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder).
>
> In jshell, try `System.getProperty("html32") + ""` you'll get a `String`.
>
> So, in `DTDBuilder.java` when none `dtd_home` property is set, the `dtd_home`
> string
On Mon, 7 Jun 2021 18:49:19 GMT, Joe Wang wrote:
> Fixes the addVariable/addParam methods in the SymbolTable to check types
> before casting.
This pull request has now been integrated.
Changeset: 1c3932f3
Author:Joe Wang
URL:
Test that when the jdk.incubator.vector module is present that libsvml.so is
present, and test the opposite case.
-
Commit messages:
- Improve test.
- Test for linux and windows
- 8268353: Test libsvml.so is and is not present in jdk image
Changes:
On Tue, 8 Jun 2021 18:32:36 GMT, Jorn Vernee wrote:
>> This patch adds a `--validate` option to the jar tool which can be used to
>> validate a jar file that might be malformed. For instance, if a jar is a
>> multi-release jar, it is malformed if different versions expose different
>> APIs.
On Tue, 8 Jun 2021 16:45:27 GMT, Alexey Semenyuk wrote:
> …ages
This pull request has now been integrated.
Changeset: bcaa2cb1
Author:Alexey Semenyuk
URL:
https://git.openjdk.java.net/jdk/commit/bcaa2cb154ae5d23a067f6e38a19a21eef8fe8e8
Stats: 115 lines in 5 files changed: 114
On Tue, 8 Jun 2021 17:25:46 GMT, Alexey Semenyuk wrote:
>> …ages
>
> Alexey Semenyuk 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
On Tue, 8 Jun 2021 14:26:43 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
On Wed, 2 Jun 2021 13:48:47 GMT, Andy Herrick wrote:
> JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed
> as SCR
This pull request has now been integrated.
Changeset: 51e8201e
Author:Andy Herrick
URL:
On Tue, 8 Jun 2021 17:25:46 GMT, Alexey Semenyuk wrote:
>> …ages
>
> Alexey Semenyuk 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
On Tue, 8 Jun 2021 17:34:58 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> ~This is part 2 of a two part upstreaming process of the patch mentioned in
>> the subject line. The patch was split into 2 in order to document 2 separate
>> specification changes that arose from a change in the implementation,
On Tue, 8 Jun 2021 17:34:58 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> ~This is part 2 of a two part upstreaming process of the patch mentioned in
>> the subject line. The patch was split into 2 in order to document 2 separate
>> specification changes that arose from a change in the implementation,
On Tue, 8 Jun 2021 17:28:21 GMT, Alan Bateman wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update error message
>
> This all looks reasonable, I just wonder if the --validate description in the
> help output
> This patch adds a `--validate` option to the jar tool which can be used to
> validate a jar file that might be malformed. For instance, if a jar is a
> multi-release jar, it is malformed if different versions expose different
> APIs.
>
> The implementation is straight forward since there
On Tue, 8 Jun 2021 18:22:55 GMT, Weijun Wang wrote:
>>> I thought about that but not sure of performance impact. Is the worst
>>> problem that more than one warnings will be printed for a single caller?
>>> It's not really harmless.
>>>
>>> As for the frame, if the warning message only
On Tue, 8 Jun 2021 17:15:29 GMT, Alan Bateman wrote:
>> I thought about that but not sure of performance impact. Is the worst
>> problem that more than one warnings will be printed for a single caller?
>> It's not really harmless.
>>
>> As for the frame, if the warning message only contain
> 8267630: Start of release updates for JDK 18
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 18 additional commits since the
last
> Hi,
>
> ~This is part 2 of a two part upstreaming process of the patch mentioned in
> the subject line. The patch was split into 2 in order to document 2 separate
> specification changes that arose from a change in the implementation, with 2
> separate CSRs. The first patch can be found
On Wed, 19 May 2021 15:36:57 GMT, Jorn Vernee wrote:
>> This patch adds a `--validate` option to the jar tool which can be used to
>> validate a jar file that might be malformed. For instance, if a jar is a
>> multi-release jar, it is malformed if different versions expose different
>> APIs.
> …ages
Alexey Semenyuk 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
> Hi,
>
> ~This is part 2 of a two part upstreaming process of the patch mentioned in
> the subject line. The patch was split into 2 in order to document 2 separate
> specification changes that arose from a change in the implementation, with 2
> separate CSRs. The first patch can be found
On Tue, 8 Jun 2021 12:22:52 GMT, Weijun Wang wrote:
> I thought about that but not sure of performance impact. Is the worst problem
> that more than one warnings will be printed for a single caller? It's not
> really harmless.
>
> As for the frame, if the warning message only contain the
On Tue, 8 Jun 2021 17:07:43 GMT, Jorn Vernee wrote:
>> Hi,
>>
>> This is part 2 of a two part upstreaming process of the patch mentioned in
>> the subject line. The patch was split into 2 in order to document 2 separate
>> specification changes that arose from a change in the implementation,
> Hi,
>
> This is part 2 of a two part upstreaming process of the patch mentioned in
> the subject line. The patch was split into 2 in order to document 2 separate
> specification changes that arose from a change in the implementation, with 2
> separate CSRs. The first patch can be found here:
…ages
-
Commit messages:
- 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages
Changes: https://git.openjdk.java.net/jdk/pull/4415/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4415=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8264144
Please review this PR which is just syncing the implementation of
DirectMethodHandleDesc.Kind.valueOf(int) with its spec. My reading of the
method's spec is that if the value of the `refKind` parameter is:
MethodHandleInfo.REF_invokeInterface, then
DirectMethodHandleDesc.Kind.valueOf(int,
> …d on macOS
>
> This patch simply round up the specified stack size to multiple of the system
> page size.
>
> Test is trivial, simply run java with -Xss option against following code. On
> MacOS, before the fix, running with `-Xss159k` and `-Xss160k` would get
> `7183` and `649`
On Tue, 8 Jun 2021 08:17:54 GMT, Thomas Stuefe wrote:
>> Henry Jen has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains seven additional commits
>>
On Tue, 8 Jun 2021 02:36:26 GMT, David Holmes wrote:
>> Henry Jen has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains seven additional commits
>>
On Mon, 7 Jun 2021 16:38:01 GMT, Jorn Vernee wrote:
> Hi,
>
> This is part 2 of a two part upstreaming process of the patch mentioned in
> the subject line. The patch was split into 2 in order to document 2 separate
> specification changes that arose from a change in the implementation, with
> Hi,
>
> This is part 2 of a two part upstreaming process of the patch mentioned in
> the subject line. The patch was split into 2 in order to document 2 separate
> specification changes that arose from a change in the implementation, with 2
> separate CSRs. The first patch can be found here:
On Tue, 8 Jun 2021 14:13:53 GMT, Jatin Bhateja wrote:
>> I must be missing something. How is the brute force loop aligned if not by
>> this directive? I don't see an alignment anywhere else that could force it.
>> After the entry(), there are pushes and length comparisons followed by the
On Mon, 7 Jun 2021 15:14:39 GMT, Jorn Vernee wrote:
> Hi,
>
> This is part 1 of a two part upstreaming process of the patch mentioned in
> the subject line. The patch was split into 2 in order to document 2 separate
> specification changes that arose from a change in the implementation, with
On Mon, 7 Jun 2021 15:14:39 GMT, Jorn Vernee wrote:
> Hi,
>
> This is part 1 of a two part upstreaming process of the patch mentioned in
> the subject line. The patch was split into 2 in order to document 2 separate
> specification changes that arose from a change in the implementation, with
On Tue, 8 Jun 2021 14:06:50 GMT, Andy Herrick wrote:
>> JDK-8267764: jpackage cannot handle window screensaver files when EXE
>> renamed as SCR
>
> Andy Herrick has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated
On Tue, 8 Jun 2021 02:23:09 GMT, liach
wrote:
>> Dan Smith has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Clean up validation of implKind REF_invokeSpecial
>
>
On Tue, 8 Jun 2021 15:17:44 GMT, Dan Smith wrote:
>> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
>> line 191:
>>
>>> 189: useImplMethodHandle =
>>> (Modifier.isProtected(implInfo.getModifiers()) &&
>>> 190:
On Tue, 8 Jun 2021 15:27:04 GMT, Dan Smith wrote:
>> Small bug fix.
>
> Dan Smith has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Clean up validation of implKind REF_invokeSpecial
> Small bug fix.
Dan Smith has updated the pull request incrementally with one additional commit
since the last revision:
Clean up validation of implKind REF_invokeSpecial
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/4403/files
- new:
On Tue, 8 Jun 2021 14:29:38 GMT, Athijegannathan Sundararajan
wrote:
>> jlink should clean up output directory on any failure. should not leave
>> partially filled output.
>
> Athijegannathan Sundararajan has updated the pull request incrementally with
> one additional commit since the last
On Fri, 4 Jun 2021 21:23:27 GMT, Nikita Gubarkov
wrote:
> I got rid of `realpath` usage as discussed in
> https://github.com/openjdk/jdk/pull/4190 and used `RelativePath` macro
> instead, however there were quite a few problems with this macro, here's the
> example:
>
> $(call
On Tue, 8 Jun 2021 14:26:43 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
On Tue, 8 Jun 2021 14:26:43 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
> jlink should clean up output directory on any failure. should not leave
> partially filled output.
Athijegannathan Sundararajan has updated the pull request incrementally with
one additional commit since the last revision:
Fixed resouce closing issue for lib/moduls file. Pre-existing
On Tue, 8 Jun 2021 11:41:28 GMT, Daniel Fuchs wrote:
>> Roger Riggs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Clarified javadoc for rejectUndecidedClass.
>> Added javadoc to describe throwing of ExceptionInInitializerError if
> JEP 415: Context-specific Deserialization Filters extends the deserialization
> filtering mechanisms with more flexible and customizable protections against
> malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415.
> The `java.io.ObjectInputFilter` and
On Mon, 7 Jun 2021 13:23:46 GMT, Jorn Vernee wrote:
> Hi,
>
> The documentation of `CLinker::systemLookup` [1] says this:
>
>
> * Obtains a system lookup which is suitable to find symbols in the standard C
> libraries.
>
>
> However, currently it is not possible to look up common stdio.h
On Tue, 8 Jun 2021 13:25:00 GMT, Scott Gibbons
wrote:
>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 6239:
>>
>>> 6237:
>>> 6238: __ align(32);
>>> 6239: __ BIND(L_bruteForce);
>>
>> Is this alignment needed ? Given that brute force loop is already aligned.
>
> I must be
> JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed
> as SCR
Andy Herrick 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
On Wed, 2 Jun 2021 13:48:47 GMT, Andy Herrick wrote:
> JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed
> as SCR
as suggested added a simple test to verify an app on windows can continue to
run after ".exe" is renamed to any other extension
-
PR:
On Fri, 4 Jun 2021 10:53:42 GMT, Maurizio Cimadamore
wrote:
> Turns out that adding more timeout is a lost cause here. The root cause of
> the slowdown when running the test in debug build is:
>
> https://bugs.openjdk.java.net/browse/JDK-8266074
>
> Which has also caused related test issues:
On Mon, 7 Jun 2021 03:18:32 GMT, Henry Jen wrote:
>> …d on macOS
>>
>> This patch simply round up the specified stack size to multiple of the
>> system page size.
>>
>> Test is trivial, simply run java with -Xss option against following code. On
>> MacOS, before the fix, running with
On Tue, 8 Jun 2021 01:56:42 GMT, Jatin Bhateja wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixing review comments. Adding notes about isMIME parameter for other
>> architectures; clarifying decodeBlock
On Tue, 8 Jun 2021 11:32:29 GMT, Alan Bateman wrote:
>> jlink should clean up output directory on any failure. should not leave
>> partially filled output.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 295:
>
>> 293: cleanupOutput(outputPath);
>> 294:
On Tue, 8 Jun 2021 12:20:32 GMT, Jorn Vernee wrote:
> WRT the test failure on Windows discussed offline: when the directory is
> deleted as a result of a `PluginException` being thrown, there is still an
> open file handle on the `lib/modules` file in the image directory, which
> prevents the
On Thu, 22 Apr 2021 13:47:03 GMT, ScientificWare
wrote:
> This concerns [dtdbuilder
> tools](https://github.com/openjdk/jdk/tree/master/make/jdk/src/classes/build/tools/dtdbuilder).
>
> In jshell, try `System.getProperty("html32") + ""` you'll get a `String`.
>
> So, in `DTDBuilder.java`
On Tue, 8 Jun 2021 06:11:17 GMT, Alan Bateman wrote:
>> More loudly and precise warning messages when a security manager is either
>> enabled at startup or installed at runtime.
>
> src/java.base/share/classes/java/lang/System.java line 331:
>
>> 329:
>> 330: // Remember original
On Mon, 7 Jun 2021 11:00:00 GMT, Athijegannathan Sundararajan
wrote:
> jlink should clean up output directory on any failure. should not leave
> partially filled output.
WRT the test failure on Windows discussed offline: when the directory is
deleted as a result of a `PluginException` being
On Tue, 8 Jun 2021 06:41:11 GMT, Alan Bateman wrote:
> > You might want to make your "WARNING" consistent with the VM's "Warning" so
> > that OutputAnalyzer's logic to ignore warnings will automatically ignore
> > these too.
>
> The uppercase "WARNING" is intentional here, it was the same
On Tue, 8 Jun 2021 10:32:49 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
On Mon, 7 Jun 2021 11:00:00 GMT, Athijegannathan Sundararajan
wrote:
> jlink should clean up output directory on any failure. should not leave
> partially filled output.
I think we need to rename the JBS issue as this is not specific to the -vm
option. Instead, this is about cleanup when
On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote:
> More loudly and precise warning messages when a security manager is either
> enabled at startup or installed at runtime.
Changes to LoggerFinderLoaderTest look reasonable to me.
-
PR: https://git.openjdk.java.net/jdk/pull/4400
> JEP 415: Context-specific Deserialization Filters extends the deserialization
> filtering mechanisms with more flexible and customizable protections against
> malicious deserialization. See JEP 415: https://openjdk.java.net/jeps/415.
> The `java.io.ObjectInputFilter` and
> Current VectorAPI Java side implementation expresses rotateLeft and
> rotateRight operation using following operations:-
>
> vec1 = lanewise(VectorOperators.LSHL, n)
> vec2 = lanewise(VectorOperators.LSHR, n)
> res = lanewise(VectorOperations.OR, vec1 , vec2)
>
> This patch moves
On Mon, 7 Jun 2021 18:46:11 GMT, Naoto Sato wrote:
>> @mkartashev thank you for the detailed explanation.
>>
>> It is not clear to me that the JDK's conformance to being a Unicode
>> application has significantly changed since the evaluation of JDK-8017274 -
>> @naotoj can you comment on
On Mon, 24 May 2021 16:43:09 GMT, Maxim Kartashev
wrote:
> Character strings within JVM are produced and consumed in several formats.
> Strings come from/to Java in the UTF8 format and POSIX APIs (like fprintf()
> or dlopen()) consume strings also in UTF8. On Windows, however, the situation
On Sun, 9 May 2021 21:59:29 GMT, Rafael Winterhalter
wrote:
> During annotation parsing, the parser assumes that a declared property is of
> an array type if the parsed annotation property is defined as an array. In
> this case, the component type is `null`, and a `NullPointerException` is
>
On Mon, 7 Jun 2021 03:18:32 GMT, Henry Jen wrote:
>> …d on macOS
>>
>> This patch simply round up the specified stack size to multiple of the
>> system page size.
>>
>> Test is trivial, simply run java with -Xss option against following code. On
>> MacOS, before the fix, running with
On Tue, 11 May 2021 14:49:42 GMT, Matthias Baesken wrote:
> Hello, please review this small Sonar finding.
> Sonar reports a potential NULL pointer dereference here :
> https://sonarcloud.io/project/issues?id=shipilev_jdk=c=AXck8CPLBBG2CXpcnh_z=false=MAJOR=BUG
> "Access to field 'item' results
> There is a few JDK classes duplicating the contents of Long.hashCode() for
> hash code calculation. They should explicitly delegate to Long.hashCode().
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated
On Tue, 8 Jun 2021 06:30:00 GMT, David Holmes wrote:
> You might want to make your "WARNING" consistent with the VM's "Warning" so
> that OutputAnalyzer's logic to ignore warnings will automatically ignore
> these too.
The uppercase "WARNING" is intentional here, it was the same with illegal
On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote:
> More loudly and precise warning messages when a security manager is either
> enabled at startup or installed at runtime.
There are a number of hotspot tests that will trigger this warning, so please
ensure they work correctly with the
On 8/06/2021 5:23 am, Daniel D.Daugherty wrote:
On Fri, 4 Jun 2021 10:53:42 GMT, Maurizio Cimadamore
wrote:
Turns out that adding more timeout is a lost cause here. The root cause of the
slowdown when running the test in debug build is:
https://bugs.openjdk.java.net/browse/JDK-8266074
On Mon, 7 Jun 2021 20:42:53 GMT, Weijun Wang wrote:
> More loudly and precise warning messages when a security manager is either
> enabled at startup or installed at runtime.
Changes requested by alanb (Reviewer).
src/java.base/share/classes/java/lang/System.java line 331:
> 329:
> 330:
81 matches
Mail list logo
