On Fri, 24 Sep 2021 23:07:33 GMT, Mandy Chung wrote:
> GenGraphs tool generates the module graph. It currently supports the
> configuration via javadoc-graphs.properties. However,
> `make/jdk/src/classes/build/tools/jigsaw/javadoc-graphs.properties` only
> documents two properties. It should b
On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which proposes to fix the issue
>> reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
>>
>> As noted in that issue, trying to class load
>> `sun.util.calendar.CalendarSystem` and `sun.
On Sat, 25 Sep 2021 03:38:24 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which proposes to fix the issue
>> reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
>>
>> As noted in that issue, trying to class load
>> `sun.util.calendar.CalendarSystem` and `sun.
On Fri, 24 Sep 2021 17:53:03 GMT, Naoto Sato wrote:
>> Jaikiran Pai has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Minor test adjustments as suggested by Naoto
>> - use a holder instead of volatile, as suggested by Roger
>
> src/java
> Can I please get a review for this change which proposes to fix the issue
> reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
>
> As noted in that issue, trying to class load
> `sun.util.calendar.CalendarSystem` and `sun.util.calendar.Gregorian`
> concurrently in separate threads
> remove vfork() on Darwin
xpbob has updated the pull request incrementally with one additional commit
since the last revision:
Drop drop "Solaris" from the comment
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/5686/files
- new: https://git.openjdk.java.net/jdk/pull
GenGraphs tool generates the module graph. It currently supports the
configuration via javadoc-graphs.properties. However,
`make/jdk/src/classes/build/tools/jigsaw/javadoc-graphs.properties` only
documents two properties. It should be updated to cover all configurable
properties.
There are a c
On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote:
> This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to
> work also for ASCII encoding, which makes for example the `UTF_8$Encoder`
> perform on par with (or outperform) similarly getting charset encoded bytes
> from
On Fri, 24 Sep 2021 09:27:02 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to
>> replace and mitigate Object.finalize() uses in the JDK libraries; please see
>> https://bugs.openjdk.java.net/browse/JDK-8253568 for more info
On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote:
> This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to
> work also for ASCII encoding, which makes for example the `UTF_8$Encoder`
> perform on par with (or outperform) similarly getting charset encoded bytes
> from
On Fri, 24 Sep 2021 14:36:07 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
>
> As noted in that issue, trying to class load
> `sun.util.calendar.CalendarSystem` and `sun.util.
On Fri, 24 Sep 2021 14:36:07 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
>
> As noted in that issue, trying to class load
> `sun.util.calendar.CalendarSystem` and `sun.util.
On Fri, 24 Sep 2021 16:18:57 GMT, xpbob
wrote:
> remove vfork() on Darwin
src/java.base/unix/native/libjava/ProcessImpl_md.c line 447:
> 445: #endif
> 446:
> 447: /* vfork(2) is deprecated on Solaris and Darwin */
Drive by comment is that we can probably drop "Solaris" from the comment.
---
remove vfork() on Darwin
-
Commit messages:
- 8274293: Build failure with Xcode 13.0 due to vfork is deprecated
Changes: https://git.openjdk.java.net/jdk/pull/5686/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5686&range=00
Issue: https://bugs.openjdk.java.net/brows
On Thu, 23 Sep 2021 00:03:55 GMT, Claes Redestad wrote:
> This can probably be simplified further, say by adding a flag to the
> intrinsic of whether we're encoding ASCII only or ISO-8859-1.
Done: Removed the addition of a new C2 Node, merged the macro assembler
encode_iso_array and encode_asc
This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to work
also for ASCII encoding, which makes for example the `UTF_8$Encoder` perform on
par with (or outperform) similarly getting charset encoded bytes from a String.
The former took a small performance hit in JDK 9, and th
On Tue, 21 Sep 2021 21:58:48 GMT, Claes Redestad wrote:
> This patch extends the `ISO_8859_1.implEncodeISOArray` intrinsic on x86 to
> work also for ASCII encoding, which makes for example the `UTF_8$Encoder`
> perform on par with (or outperform) similarly getting charset encoded bytes
> from
On Thu, 11 Feb 2021 19:23:55 GMT, Roger Riggs wrote:
>> On Mac Os X, the OSVersionTest detected a difference in the version number
>> reported in the os.version property
>> and the version number provided by `sw_vers -productVersion`.
>>
>> When the java runtime is built with XCode 11.3, the os
Can I please get a review for this change which proposes to fix the issue
reported in https://bugs.openjdk.java.net/browse/JDK-8273790?
As noted in that issue, trying to class load `sun.util.calendar.CalendarSystem`
and `sun.util.calendar.Gregorian` concurrently in separate threads can lead to
On Thu, 11 Feb 2021 19:23:55 GMT, Roger Riggs wrote:
>> On Mac Os X, the OSVersionTest detected a difference in the version number
>> reported in the os.version property
>> and the version number provided by `sw_vers -productVersion`.
>>
>> When the java runtime is built with XCode 11.3, the os
On Thu, 11 Feb 2021 19:23:55 GMT, Roger Riggs wrote:
>> On Mac Os X, the OSVersionTest detected a difference in the version number
>> reported in the os.version property
>> and the version number provided by `sw_vers -productVersion`.
>>
>> When the java runtime is built with XCode 11.3, the os
On Thu, 11 Feb 2021 19:23:55 GMT, Roger Riggs wrote:
>> On Mac Os X, the OSVersionTest detected a difference in the version number
>> reported in the os.version property
>> and the version number provided by `sw_vers -productVersion`.
>>
>> When the java runtime is built with XCode 11.3, the os
On Thu, 23 Sep 2021 19:47:51 GMT, Andrey Turbanov
wrote:
> Usages of methods Integer.valueOf, Byte.valueOf, Short.valueOf,
> Float.valueOf, Double.valueOf, Long.valueOf often can be simplified by using
> their pair methods parseInt/parseLong/parseShort/parseByte/parseFloat.
This pull request
On Thu, 23 Sep 2021 20:03:29 GMT, Andy Herrick wrote:
> JDK-8274087: Windows DLL path not set correctly.
This pull request has now been integrated.
Changeset: f36a2bbd
Author:Andy Herrick
URL:
https://git.openjdk.java.net/jdk/commit/f36a2bbd15d94d4371c2117ce08b7f04a0d59da4
Stats:
On Fri, 24 Sep 2021 11:14:00 GMT, Daniel Fuchs wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8274276: Make URLClassPath.Loader.getBaseURL() final
>
> This is calling an overidable method within a constructor, w
> Currently on each invocation of `URLClassPath.FileLoader.getResource()`
> `normalizedBase` URL is recalculated using same final `baseURL` from parent
> class. This can be avoided giving significant improvement in memory
> consumption. Consider the benchmark:
>
> @State(Scope.Benchmark)
> @Ben
Could you please review the 8250678 bug fixes?
The `parse` method of ModuleDescriptor.Version class behaves incorrectly when
the input string contains consecutive delimiters.
The `parse` method treats strings as three sections, but the parsing method
differs between the method for the version s
On Fri, 24 Sep 2021 10:35:54 GMT, Сергей Цыпанов
wrote:
> Currently on each invocation of `URLClassPath.FileLoader.getResource()`
> `normalizedBase` URL is recalculated using same final `baseURL` from parent
> class. This can be avoided giving significant improvement in memory
> consumption.
Currently on each invocation of `URLClassPath.FileLoader.getResource()`
`normalizedBase` URL is recalculated using same final `baseURL` from parent
class. This can be avoided giving significant improvement in memory
consumption. Consider the benchmark:
@State(Scope.Benchmark)
@BenchmarkMode(Mod
On Thu, 23 Sep 2021 22:35:26 GMT, Coleen Phillimore wrote:
>> Markus Grönlund has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - remove rehashing and rely on default grow_hint for table resize
>> - mtStatistics
>
> src/hotspot/share/jfr/
> Greetings,
>
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to
> replace and mitigate Object.finalize() uses in the JDK libraries; please see
> https://bugs.openjdk.java.net/browse/JDK-8253568 for more information.
>
> We also like to assist users in replacing and mit
31 matches
Mail list logo