Re: RFR: JDK-8248904: Add support to jpackage for the Mac App Store
On Wed, 24 Feb 2021 21:59:22 GMT, Andy Herrick wrote: > Implementation of Mac App Support including three new mac specific CLI > options. Marked as reviewed by almatvee (Committer). - PR: https://git.openjdk.java.net/jdk/pull/2716
Re: RFR: 8263102: Expand documention of Method.isBridge [v3]
On Tue, 9 Mar 2021 03:27:29 GMT, Joe Darcy wrote:
>> The existing documentation of Method.isBridge isn't terribly helpful to the
>> reader. This RFE proposes to given a common example of how bridge methods
>> are used. The JLS does *not* have a section discussing bridge methods in
>> detail; bridge methods are a compilation technique for lowering the Java
>> language to the JVM, they are not a language feature per se. The example
>> given is not exhaustive; there can be and are other uses of bridge methods.
>>
>> Once the text is agreed to; I'll update the copyright year as well.
>
> 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/Method.java line 589:
> 587: * different return type, the virtual machine does not.
> 588: * A
> 589: * common case where covariant overrides are used is for a {@link
I think the example should be clearer because here, you don't show the code of
EnumSet.clone().
I wonder if it's not easier if all the code is visible
interface I {
Object m();
}
class A implements I {
String m() { return "hello"; }
}
so you can explain that the VM do the dispatch on I::m()Object so the compiler
has to insert a method A::m()Object,
the bridge method with this pseudo-code
class A implements I {
/* bridge */ Object m() { return m(); } // calls m()String
String m() { return "hello"; }
}
-
PR: https://git.openjdk.java.net/jdk/pull/2852
Re: RFR: 8263102: Expand documention of Method.isBridge [v2]
Hi Stuart, On 3/8/2021 6:02 PM, Stuart Marks wrote: On Sat, 6 Mar 2021 17:44:18 GMT, Joe Darcy wrote: The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods. Once the text is agreed to; I'll update the copyright year as well. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Improve linkage for isSynethetic. src/java.base/share/classes/java/lang/reflect/Method.java line 593: 591: * result. (While the Java language specification forbids a class 592: * declaring two methods with the same parameter types but a 593: * different return type, the virtual machine does not.) I'm of two minds about this. This is certainly a good example of a bridge method. It doesn't motivate _why_ a bridge method is necessary in this case. It think it's because the language says you should be able to write code like EnumSet es2 = es.clone(); so there needs to be a method defined in the class file whose return type is assignment-compatible with `EnumSet`. However, a `clone` method that returns `Object` is the only one that can override the `Object::clone` method. Thus, a something is necessary to span this gap -- a bridge method. On the other hand, this might be too much detail for here. This is a really obscure location. It seems like somewhere else would be better, and where a full explanation with examples can be provided. If someone is looking at isBridge and wondering what it does, having some discussion there some reasonable :-) The text in question is not intended to be exhaustive and the exact use of bridge methods can, in principle, be Java compiler dependent. Also, if in the future there are new JVM/platform facilities added so that bridge methods are not necessarily required for the cases where they are now used, I intended to write this text so it would still be correct. Thanks, -Joe
Re: RFR: 8263102: Expand documention of Method.isBridge [v3]
> The existing documentation of Method.isBridge isn't terribly helpful to the > reader. This RFE proposes to given a common example of how bridge methods are > used. The JLS does *not* have a section discussing bridge methods in detail; > bridge methods are a compilation technique for lowering the Java language to > the JVM, they are not a language feature per se. The example given is not > exhaustive; there can be and are other uses of bridge methods. > > Once the text is agreed to; I'll update the copyright year as well. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. - Changes: - all: https://git.openjdk.java.net/jdk/pull/2852/files - new: https://git.openjdk.java.net/jdk/pull/2852/files/d3b7a3c3..44552784 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2852=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2852=01-02 Stats: 20 lines in 1 file changed: 9 ins; 7 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2852.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2852/head:pull/2852 PR: https://git.openjdk.java.net/jdk/pull/2852
Re: RFR: 8263102: Expand documention of Method.isBridge [v2]
On Tue, 9 Mar 2021 01:58:38 GMT, Stuart Marks wrote: >> Joe Darcy has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Improve linkage for isSynethetic. > > src/java.base/share/classes/java/lang/reflect/Method.java line 597: > >> 595: * Bridge methods may also be used by Java compiler in other >> 596: * circumstances to span across difference in Java Language >> 597: * semantics and JVM semantics. > > If you decide to put less detail here, you could start with this statement. I > think the main point is that there are some semantic gaps between methods in > the Java language and in the JVM; bridge methods are necessary to "span" this > gap. You might simply list some examples without explaining them fully. > > Would this be "used by **a** Java compiler" or "used by **the** Java compiler? Imo "created" should be better. Is there any case where a java compiler accepts bridge methods generated? - PR: https://git.openjdk.java.net/jdk/pull/2852
Re: RFR: 8263102: Expand documention of Method.isBridge [v2]
On Sat, 6 Mar 2021 17:44:18 GMT, Joe Darcy wrote: >> The existing documentation of Method.isBridge isn't terribly helpful to the >> reader. This RFE proposes to given a common example of how bridge methods >> are used. The JLS does *not* have a section discussing bridge methods in >> detail; bridge methods are a compilation technique for lowering the Java >> language to the JVM, they are not a language feature per se. The example >> given is not exhaustive; there can be and are other uses of bridge methods. >> >> Once the text is agreed to; I'll update the copyright year as well. > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Improve linkage for isSynethetic. src/java.base/share/classes/java/lang/reflect/Method.java line 593: > 591: * result. (While the Java language specification forbids a class > 592: * declaring two methods with the same parameter types but a > 593: * different return type, the virtual machine does not.) I'm of two minds about this. This is certainly a good example of a bridge method. It doesn't motivate _why_ a bridge method is necessary in this case. It think it's because the language says you should be able to write code like EnumSet es2 = es.clone(); so there needs to be a method defined in the class file whose return type is assignment-compatible with `EnumSet`. However, a `clone` method that returns `Object` is the only one that can override the `Object::clone` method. Thus, a something is necessary to span this gap -- a bridge method. On the other hand, this might be too much detail for here. This is a really obscure location. It seems like somewhere else would be better, and where a full explanation with examples can be provided. src/java.base/share/classes/java/lang/reflect/Method.java line 597: > 595: * Bridge methods may also be used by Java compiler in other > 596: * circumstances to span across difference in Java Language > 597: * semantics and JVM semantics. If you decide to put less detail here, you could start with this statement. I think the main point is that there are some semantic gaps between methods in the Java language and in the JVM; bridge methods are necessary to "span" this gap. You might simply list some examples without explaining them fully. Would this be "used by **a** Java compiler" or "used by **the** Java compiler? - PR: https://git.openjdk.java.net/jdk/pull/2852
RFR: 8262001: java/lang/management/ThreadMXBean/ResetPeakThreadCount.java failed with "RuntimeException: Current Peak = 14 Expected to be == previous peak = 7 + 8"
The fix updates ResetPeakThreadCount.java test - increases number of threads, but relaxes conditions so start/termination of system threads don't cause failures. Additional changes: - store threads in a list instead of array (we need only to start/terminate some number of threads, so linked list works better); - flags for thread termination are moved to thread class; - store values from ThreadMXBean.getPeakThreadCount() and getThreadCount() in int instead of long (the methods return int values) - Commit messages: - Update ResetPeakThreadCount.java Changes: https://git.openjdk.java.net/jdk/pull/2885/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2885=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262001 Stats: 139 lines in 1 file changed: 20 ins; 61 del; 58 mod Patch: https://git.openjdk.java.net/jdk/pull/2885.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2885/head:pull/2885 PR: https://git.openjdk.java.net/jdk/pull/2885
Re: RFR: 8263105: security-libs doclint cleanup [v2]
On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore wrote: >> Fix various things pointed out by the most recent doclint run in the >> security-libs area. >> >> This is docs only: I will be checking doccheck/doclint, and will be running >> tier1/tier2 tests. Minor spot checks on generated files. > > Bradford Wetmore has updated the pull request incrementally with one > additional commit since the last revision: > > Codereview Comment Looks fine. - Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2856
Integrated: 8263135: unique_ptr should not be used for types that are not pointers
On Sun, 7 Mar 2021 03:15:46 GMT, Yasumasa Suenaga wrote: > I saw error during jpackage compilation with VS 2019 (16.9.0) as following > (on Japanese locale): > > c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): > error C2440: '=': '_Other' から '_Ty' に変換できません。 > with > [ > _Other=nullptr > ] > and > [ > _Ty=unsigned long > ] > c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): > note: ネイティブの nullptr はブールに変換するか、または reinterpret_cast を使用して整数型に変換することのみが可能です > c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3423): > note: コンパイル対象の関数 テンプレート インスタンス化 '_Ty std::exchange<_Ty2,nullptr>(_Ty > &,_Other &&) noexcept(false)' のリファレンスを確認してください > with > [ > _Ty=unsigned long, > _Ty2=unsigned long, > _Other=nullptr > ] > c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3422): > note: クラス テンプ レート メンバー関数 'unsigned long > std::unique_ptr::release(void) noexcept' > のコンパイル中 > d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.cpp(237): > note: コンパイル対象の関数 テンプレート インスタンス化 'unsigned long > std::unique_ptr::release(void) noexcept' > のリファレンスを確認してください > d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.h(119): > note: コンパイル対象の クラ ス テンプレート インスタンス化 > 'std::unique_ptr' のリファレンスを確認してください > > `UniqueMSIHANDLE` is declared in MsiUtils.h as `unique_ptr` for `MSIHANDLE`. > `MSIHANDLE` seems to be declared as synonym for `unsigned long`, not a > pointer type. > I think `MSIHANDLE` does not need to handle as `unique_ptr` if it releases at > d'tor of the class which holds it (`Database`, `DatabaseRecord`). This pull request has now been integrated. Changeset: 4e947607 Author:Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/4e947607 Stats: 77 lines in 4 files changed: 14 ins; 36 del; 27 mod 8263135: unique_ptr should not be used for types that are not pointers Reviewed-by: asemenyuk, herrick - PR: https://git.openjdk.java.net/jdk/pull/2858
Re: RFR: 8263105: security-libs doclint cleanup [v2]
> Fix various things pointed out by the most recent doclint run in the > security-libs area. > > This is docs only: I will be checking doccheck/doclint, and will be running > tier1/tier2 tests. Minor spot checks on generated files. Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision: Codereview Comment - Changes: - all: https://git.openjdk.java.net/jdk/pull/2856/files - new: https://git.openjdk.java.net/jdk/pull/2856/files/f2253d91..1fa29ea6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2856=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2856=00-01 Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2856.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2856/head:pull/2856 PR: https://git.openjdk.java.net/jdk/pull/2856
Re: RFR: 8263105: security-libs doclint cleanup
On Sat, 6 Mar 2021 07:31:09 GMT, Bradford Wetmore wrote:
> Fix various things pointed out by the most recent doclint run in the
> security-libs area.
>
> This is docs only: I will be checking doccheck/doclint, and will be running
> tier1/tier2 tests. Minor spot checks on generated files.
I'm happy to see a reduction in the number of warnings.
I suspect there are a few places where Object{In,Out}putStream is fully
qualified when it's not strictly necessary; however, since this is in
pre-existing code, I don't think this needs to be changed now.
src/java.base/share/classes/java/security/KeyPair.java line 53:
> 51:
> 52: /**
> 53: *
Extra line?
-
Marked as reviewed by iris (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2856
Re: RFR: 8263105: security-libs doclint cleanup
On Sat, 6 Mar 2021 19:20:39 GMT, Jonathan Gibbons wrote:
>> Fix various things pointed out by the most recent doclint run in the
>> security-libs area.
>>
>> This is docs only: I will be checking doccheck/doclint, and will be running
>> tier1/tier2 tests. Minor spot checks on generated files.
>
> src/java.base/share/classes/java/security/BasicPermission.java line 497:
>
>> 495: /**
>> 496: * @serialData Default fields.
>> 497: */
>
> FWIW, this doc comment will be ignored, because it will be superseded by the
> new comment on line 499. At some point doen the road, you may get a warning
> from javac about an ignored doc comment.
Ok
> src/java.base/share/classes/java/security/GuardedObject.java line 64:
>
>> 62:
>> 63: /**
>> 64: * The guard object
>
> add a period?
Probably worth doing as it's the first sentence.
> src/java.base/share/classes/java/security/PermissionCollection.java line 105:
>
>> 103: * Whether this permission collection is read-only.
>> 104: *
>> 105: * If set, add() will throw an exception.
>
> maybe use `{@code}` or `{@link}` on add?
Done.
> src/java.base/share/classes/java/security/Permissions.java line 581:
>
>> 579: /**
>> 580: * @serialData Default fields.
>> 581: */
>
> Another ignored comment. I suggest just changing these to `/*` comments.
Good idea. Done.
-
PR: https://git.openjdk.java.net/jdk/pull/2856
Re: RFR: 8263105: security-libs doclint cleanup
On Sat, 6 Mar 2021 07:31:09 GMT, Bradford Wetmore wrote:
> Fix various things pointed out by the most recent doclint run in the
> security-libs area.
>
> This is docs only: I will be checking doccheck/doclint, and will be running
> tier1/tier2 tests. Minor spot checks on generated files.
I've read the first 10 files. The edits are definitely in the right direction,
and will address the "missing comments" issues.
I'll leave it up to you and the others in your team to decide what level of
stylistic consistency you would like for the new comments, but just having a
relevant comment at all is a great start.
src/java.base/share/classes/java/security/BasicPermission.java line 497:
> 495: /**
> 496: * @serialData Default fields.
> 497: */
FWIW, this doc comment will be ignored, because it will be superseded by the
new comment on line 499. At some point doen the road, you may get a warning
from javac about an ignored doc comment.
src/java.base/share/classes/java/security/GuardedObject.java line 64:
> 62:
> 63: /**
> 64: * The guard object
add a period?
src/java.base/share/classes/java/security/PermissionCollection.java line 105:
> 103: * Whether this permission collection is read-only.
> 104: *
> 105: * If set, add() will throw an exception.
maybe use `{@code}` or `{@link}` on add?
src/java.base/share/classes/java/security/Permissions.java line 581:
> 579: /**
> 580: * @serialData Default fields.
> 581: */
Another ignored comment. I suggest just changing these to `/*` comments.
-
PR: https://git.openjdk.java.net/jdk/pull/2856
RFR: 8263105: security-libs doclint cleanup
Fix various things pointed out by the most recent doclint run in the security-libs area. This is docs only: I will be checking doccheck/doclint, and will be running tier1/tier2 tests. Minor spot checks on generated files. - Commit messages: - Final First Draft - Only 100 warnings output by default - 8263105: security-libs doclint cleanup Changes: https://git.openjdk.java.net/jdk/pull/2856/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2856=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263105 Stats: 351 lines in 39 files changed: 270 ins; 2 del; 79 mod Patch: https://git.openjdk.java.net/jdk/pull/2856.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2856/head:pull/2856 PR: https://git.openjdk.java.net/jdk/pull/2856
Integrated: 8263038: Optimize String.format for simple specifiers
On Thu, 4 Mar 2021 17:20:40 GMT, Claes Redestad wrote:
> This patch optimizes String.format expressions that uses trivial specifiers.
> In the JDK, the most common variation of String.format is a variation of
> format("foo: %s", s), which gets a significant speed-up from this.
>
> Various other cleanups and minor improvements reduce overhead further and
> ensure we get a small gain also for more complex format strings.
This pull request has now been integrated.
Changeset: f71b21b0
Author:Claes Redestad
URL: https://git.openjdk.java.net/jdk/commit/f71b21b0
Stats: 281 lines in 2 files changed: 126 ins; 58 del; 97 mod
8263038: Optimize String.format for simple specifiers
Reviewed-by: rriggs, naoto
-
PR: https://git.openjdk.java.net/jdk/pull/2830
Re: RFR: 8263038: Optimize String.format for simple specifiers [v4]
On Mon, 8 Mar 2021 21:42:08 GMT, Naoto Sato wrote: >> Claes Redestad has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Better words > > Looks good! Thank you for reviews, Roger and Naoto! - PR: https://git.openjdk.java.net/jdk/pull/2830
RFR: 8241716: Jpackage functionality to let users choose whether to create shortcuts
Add support to insert dialog with prompts to create shortcuts in dialog installation sequence of Windows installers created by jpackage. As a side effect of the fix, UI-related WiX source code was moved from main.wxs into generated ui.wxf file. Users can override ui.wxf by placing a file with this name in resource directory. Custom dialogs optionally inserted in dialog installation sequence were placed in distinct WiX sources: InstallDirNotEmptyDlg.wxs and ShortcutPromptDlg.wxs. They can be overridden if files with the corresponding names as placed in resource directory. Moving source code of installer UI from main.wxs into ui.wxf, InstallDirNotEmptyDlg.wxs and ShortcutPromptDlg.wxs files supposed to simplify overriding of the default UI provided by jpackage. - Commit messages: - 8241716: Jpackage functionality to let users choose whether to create shortcuts - 8241716: Jpackage functionality to let users choose whether to create shortcuts Changes: https://git.openjdk.java.net/jdk/pull/2882/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2882=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241716 Stats: 3069 lines in 23 files changed: 2062 ins; 988 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/2882.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2882/head:pull/2882 PR: https://git.openjdk.java.net/jdk/pull/2882
Re: RFR: 8261366: Add discussion of IEEE 754 to BigDecimal [v3]
> Informative update to BigDecimal and related classes to latest IEEE 754 > terminology, including a discussion of the similarities and differences of > BigDecimal and IEEE 754 decimal arithmetic. > > Once the wording is finalized, I'll reflow any modified paragraphs and update > the copyright years, etc. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Reflow paragraphs and update copyrights. - Changes: - all: https://git.openjdk.java.net/jdk/pull/2868/files - new: https://git.openjdk.java.net/jdk/pull/2868/files/a29d60fd..39c20d67 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2868=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2868=01-02 Stats: 20 lines in 3 files changed: 2 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/2868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2868/head:pull/2868 PR: https://git.openjdk.java.net/jdk/pull/2868
Integrated: 8261366: Add discussion of IEEE 754 to BigDecimal
On Mon, 8 Mar 2021 07:23:25 GMT, Joe Darcy wrote: > Informative update to BigDecimal and related classes to latest IEEE 754 > terminology, including a discussion of the similarities and differences of > BigDecimal and IEEE 754 decimal arithmetic. > > Once the wording is finalized, I'll reflow any modified paragraphs and update > the copyright years, etc. This pull request has now been integrated. Changeset: 14cfbda3 Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/14cfbda3 Stats: 104 lines in 3 files changed: 62 ins; 3 del; 39 mod 8261366: Add discussion of IEEE 754 to BigDecimal Reviewed-by: bpb - PR: https://git.openjdk.java.net/jdk/pull/2868
Re: RFR: 8261366: Add discussion of IEEE 754 to BigDecimal [v2]
On Mon, 8 Mar 2021 21:07:22 GMT, Joe Darcy wrote: >> Informative update to BigDecimal and related classes to latest IEEE 754 >> terminology, including a discussion of the similarities and differences of >> BigDecimal and IEEE 754 decimal arithmetic. >> >> Once the wording is finalized, I'll reflow any modified paragraphs and >> update the copyright years, etc. > > Joe Darcy has updated the pull request incrementally with one additional > commit since the last revision: > > Fix typos found in review. Looks fine. - Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2868
Re: RFR: 8263038: Optimize String.format for simple specifiers [v4]
On Mon, 8 Mar 2021 20:42:21 GMT, Claes Redestad wrote:
>> This patch optimizes String.format expressions that uses trivial specifiers.
>> In the JDK, the most common variation of String.format is a variation of
>> format("foo: %s", s), which gets a significant speed-up from this.
>>
>> Various other cleanups and minor improvements reduce overhead further and
>> ensure we get a small gain also for more complex format strings.
>
> Claes Redestad has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Better words
Looks good!
-
Marked as reviewed by naoto (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2830
RFR: 8262351: Extra '0' in java.util.Formatter for '%012a' conversion with a sign character
This fixes a zero-adding issue observed in the hex float conversion. - Commit messages: - Fixing zero-padding issue in hex float conversion Changes: https://git.openjdk.java.net/jdk/pull/2881/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2881=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262351 Stats: 55 lines in 2 files changed: 54 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2881.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2881/head:pull/2881 PR: https://git.openjdk.java.net/jdk/pull/2881
Re: RFR: 8261366: Add discussion of IEEE 754 to BigDecimal [v2]
> Informative update to BigDecimal and related classes to latest IEEE 754 > terminology, including a discussion of the similarities and differences of > BigDecimal and IEEE 754 decimal arithmetic. > > Once the wording is finalized, I'll reflow any modified paragraphs and update > the copyright years, etc. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix typos found in review. - Changes: - all: https://git.openjdk.java.net/jdk/pull/2868/files - new: https://git.openjdk.java.net/jdk/pull/2868/files/1ff051bb..a29d60fd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=2868=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=2868=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/2868.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2868/head:pull/2868 PR: https://git.openjdk.java.net/jdk/pull/2868
Re: RFR: 8261366: Add discussion of IEEE 754 to BigDecimal
Thanks for the review Florent; will fix in the next push,
-Joe
On 3/8/2021 1:57 AM, Florent Guillaume wrote:
On Mon, 8 Mar 2021 07:23:25 GMT, Joe Darcy wrote:
Informative update to BigDecimal and related classes to latest IEEE 754
terminology, including a discussion of the similarities and differences of
BigDecimal and IEEE 754 decimal arithmetic.
Once the wording is finalized, I'll reflow any modified paragraphs and update
the copyright years, etc.
src/java.base/share/classes/java/math/BigDecimal.java line 250:
248: * values of a given format and produce a result in the same format.
249: * A {@code BigDecimal}'s {@linkplain scale() scale} is equivalent to
250: * negating an IEEE 754 value's exponent. {@code BigDecimal} values to
_to_ -> _do_
src/java.base/share/classes/java/math/BigDecimal.java line 260:
258: * in {@code BigDecimal}, if a nonzero three-digit number and a
259: * nonzero four-digit number are multiplied together in the context of
260: * a {@code MathContext} object has a precision of three, the result
_has_ -> _having_
src/java.base/share/classes/java/math/BigDecimal.java line 275:
273: * numerical values computed can differ if the exponent range of the
274: * IEEE 754 format being approximated is exceeded since a {@code
275: * MathContext} does not curtail the scale {@code BigDecimal}
_the scale_ -> _the scale of_
Suggest using another word than _curtail_, whose meaning will not be
immediately clear to non-native readers as it's not a technical term.
src/java.base/share/classes/java/math/BigDecimal.java line 277:
275: * MathContext} does not curtail the scale {@code BigDecimal}
276: * results. Operations that would generate a NaN or exact infinity,
277: * such as dividing by zero, throw an {@code Arithmetic-Exception} in
`Arithmetic-Exception` -> `ArithmeticException`
-
PR: https://git.openjdk.java.net/jdk/pull/2868
Re: RFR: 8263038: Optimize String.format for simple specifiers [v4]
> This patch optimizes String.format expressions that uses trivial specifiers.
> In the JDK, the most common variation of String.format is a variation of
> format("foo: %s", s), which gets a significant speed-up from this.
>
> Various other cleanups and minor improvements reduce overhead further and
> ensure we get a small gain also for more complex format strings.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Better words
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/2830/files
- new: https://git.openjdk.java.net/jdk/pull/2830/files/c0a7f911..cc62cc94
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk=2830=03
- incr: https://webrevs.openjdk.java.net/?repo=jdk=2830=02-03
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.java.net/jdk/pull/2830.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/2830/head:pull/2830
PR: https://git.openjdk.java.net/jdk/pull/2830
Re: RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable
On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, > `java.math`, and `java.text` packages to make use of the `instanceof` pattern > variable? > > Kind regards, > Patrick Marked as reviewed by redestad (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2879
Integrated: 8260664: Phaser.arrive() memory consistency effects
On Wed, 3 Feb 2021 21:55:54 GMT, Martin Buchholz wrote: > 8260664: Phaser.arrive() memory consistency effects This pull request has now been integrated. Changeset: eb4a8af5 Author:Martin Buchholz URL: https://git.openjdk.java.net/jdk/commit/eb4a8af5 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8260664: Phaser.arrive() memory consistency effects Reviewed-by: dl - PR: https://git.openjdk.java.net/jdk/pull/2388
Re: RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable
On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, > `java.math`, and `java.text` packages to make use of the `instanceof` pattern > variable? > > Kind regards, > Patrick Marked as reviewed by smarks (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2879
Re: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException [v5]
On Sat, 6 Mar 2021 01:35:28 GMT, Craig Andrews
wrote:
>> `java.net.URLClassLoader.getResource` can throw an undocumented
>> `IllegalArgumentException`.
>>
>> According to the javadoc for the `getResource` and `findResource` methods,
>> neither should be throwing `IllegalArgumentException` - they should return
>> null if the resource can't be resolved.
>>
>> Quoting the javadoc for
>> [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>>> Returns:
>>> a URL for the resource, or null if the resource could not be found, or
>>> if the loader is closed.
>>
>> And quoting the javadoc for
>> [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>>> Returns:
>>> URL object for reading the resource; null if the resource could not be
>>> found, a URL could not be constructed to locate the resource, the resource
>>> is in a package that is not opened unconditionally, or access to the
>>> resource is denied by the security manager.
>>
>> Neither mentions throwing `IllegalArgumentException` and both are clear that
>> when URL can't be constructed, `null` should be returned.
>>
>> Here's a stack trace:
>> java.lang.IllegalArgumentException: name
>> at
>> java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>> at
>> java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>> at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>> at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>> at java.base/java.security.AccessController.doPrivileged(Native
>> Method)
>> at
>> java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
>>
>> Looking at
>> [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>> URL findResource(final String name, boolean check) {
>> URL url;
>> try {
>> url = new URL(base, ParseUtil.encodePath(name, false));
>> } catch (MalformedURLException e) {
>> throw new IllegalArgumentException("name");
>> }
>>
>> Instead of throwing `IllegalArgumentException`, that line should simply
>> return `null`.
>>
>> A similar issue exists at
>> [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>> URL findResource(final String name, boolean check) {
>> URL url;
>> try {
>> url = new URL(base, ParseUtil.encodePath(name, false));
>> } catch (MalformedURLException e) {
>> throw new IllegalArgumentException("name");
>> }
>>
>> Instead of throwing `IllegalArgumentException`, that line should simply
>> return `null`.
>
> Craig Andrews has refreshed the contents of this pull request, and previous
> commits have been removed. The incremental views will show differences
> compared to the previous content of the PR. The pull request contains one new
> commit since the last revision:
>
> JDK-8262277: java.net.URLClassLoader.getResource throws undocumented
> IllegalArgumentException
Looks good, thanks!
-
Marked as reviewed by bchristi (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/2662
Re: RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable
On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, > `java.math`, and `java.text` packages to make use of the `instanceof` pattern > variable? > > Kind regards, > Patrick Marked as reviewed by dfuchs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2879
Re: RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable
On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, > `java.math`, and `java.text` packages to make use of the `instanceof` pattern > variable? > > Kind regards, > Patrick Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2879
Re: RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable
On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, > `java.math`, and `java.text` packages to make use of the `instanceof` pattern > variable? > > Kind regards, > Patrick Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2879
Re: RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable
On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, > `java.math`, and `java.text` packages to make use of the `instanceof` pattern > variable? > > Kind regards, > Patrick Marked as reviewed by naoto (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2879
Re: RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable
On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, > `java.math`, and `java.text` packages to make use of the `instanceof` pattern > variable? > > Kind regards, > Patrick Looks good - Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2879
Re: RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable
On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the `java.io`, > `java.math`, and `java.text` packages to make use of the `instanceof` pattern > variable? > > Kind regards, > Patrick Looks good and builds cleanly: approved. - Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2879
Re: RFR: 8263038: Optimize String.format for simple specifiers [v3]
On Mon, 8 Mar 2021 18:52:19 GMT, Claes Redestad wrote:
>> This patch optimizes String.format expressions that uses trivial specifiers.
>> In the JDK, the most common variation of String.format is a variation of
>> format("foo: %s", s), which gets a significant speed-up from this.
>>
>> Various other cleanups and minor improvements reduce overhead further and
>> ensure we get a small gain also for more complex format strings.
>
> Claes Redestad has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Use a BOM as a sentinel for uninitialized zero
src/java.base/share/classes/java/util/Formatter.java line 1936:
> 1934: private IOException lastException;
> 1935:
> 1936: // Non-unicode code point value used to mark zero as uninitialized
Sorry for being anal here, but BOM is a "noncharacter", a valid Unicode code
point. So "noncharacter" over "Non-unicode code point" seems appropriate.
http://www.unicode.org/faq/private_use.html#nonchar1
-
PR: https://git.openjdk.java.net/jdk/pull/2830
Re: RFR: 8263135: unique_ptr should not be used for types that are not pointers
On Sun, 7 Mar 2021 03:15:46 GMT, Yasumasa Suenaga wrote: > I saw error during jpackage compilation with VS 2019 (16.9.0) as following > (on Japanese locale): > > c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): > error C2440: '=': '_Other' から '_Ty' に変換できません。 > with > [ > _Other=nullptr > ] > and > [ > _Ty=unsigned long > ] > c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): > note: ネイティブの nullptr はブールに変換するか、または reinterpret_cast を使用して整数型に変換することのみが可能です > c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3423): > note: コンパイル対象の関数 テンプレート インスタンス化 '_Ty std::exchange<_Ty2,nullptr>(_Ty > &,_Other &&) noexcept(false)' のリファレンスを確認してください > with > [ > _Ty=unsigned long, > _Ty2=unsigned long, > _Other=nullptr > ] > c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3422): > note: クラス テンプ レート メンバー関数 'unsigned long > std::unique_ptr::release(void) noexcept' > のコンパイル中 > d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.cpp(237): > note: コンパイル対象の関数 テンプレート インスタンス化 'unsigned long > std::unique_ptr::release(void) noexcept' > のリファレンスを確認してください > d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.h(119): > note: コンパイル対象の クラ ス テンプレート インスタンス化 > 'std::unique_ptr' のリファレンスを確認してください > > `UniqueMSIHANDLE` is declared in MsiUtils.h as `unique_ptr` for `MSIHANDLE`. > `MSIHANDLE` seems to be declared as synonym for `unsigned long`, not a > pointer type. > I think `MSIHANDLE` does not need to handle as `unique_ptr` if it releases at > d'tor of the class which holds it (`Database`, `DatabaseRecord`). Marked as reviewed by herrick (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2858
Re: RFR: 8263135: unique_ptr should not be used for types that are not pointers
On Sun, 7 Mar 2021 03:15:46 GMT, Yasumasa Suenaga wrote: > I saw error during jpackage compilation with VS 2019 (16.9.0) as following > (on Japanese locale): > > c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): > error C2440: '=': '_Other' から '_Ty' に変換できません。 > with > [ > _Other=nullptr > ] > and > [ > _Ty=unsigned long > ] > c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): > note: ネイティブの nullptr はブールに変換するか、または reinterpret_cast を使用して整数型に変換することのみが可能です > c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3423): > note: コンパイル対象の関数 テンプレート インスタンス化 '_Ty std::exchange<_Ty2,nullptr>(_Ty > &,_Other &&) noexcept(false)' のリファレンスを確認してください > with > [ > _Ty=unsigned long, > _Ty2=unsigned long, > _Other=nullptr > ] > c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3422): > note: クラス テンプ レート メンバー関数 'unsigned long > std::unique_ptr::release(void) noexcept' > のコンパイル中 > d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.cpp(237): > note: コンパイル対象の関数 テンプレート インスタンス化 'unsigned long > std::unique_ptr::release(void) noexcept' > のリファレンスを確認してください > d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.h(119): > note: コンパイル対象の クラ ス テンプレート インスタンス化 > 'std::unique_ptr' のリファレンスを確認してください > > `UniqueMSIHANDLE` is declared in MsiUtils.h as `unique_ptr` for `MSIHANDLE`. > `MSIHANDLE` seems to be declared as synonym for `unsigned long`, not a > pointer type. > I think `MSIHANDLE` does not need to handle as `unique_ptr` if it releases at > d'tor of the class which holds it (`Database`, `DatabaseRecord`). Marked as reviewed by asemenyuk (Committer). - PR: https://git.openjdk.java.net/jdk/pull/2858
Re: RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable
Looks good! Glad to see the Amber features finding their way into the codebase. On 3/8/2021 1:53 PM, Patrick Concannon wrote: Hi, Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable? Kind regards, Patrick - Commit messages: - 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable Changes: https://git.openjdk.java.net/jdk/pull/2879/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2879=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263190 Stats: 60 lines in 15 files changed: 0 ins; 27 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/2879.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2879/head:pull/2879 PR: https://git.openjdk.java.net/jdk/pull/2879
Re: RFR: 8263038: Optimize String.format for simple specifiers [v2]
On Mon, 8 Mar 2021 17:23:05 GMT, Naoto Sato wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Lazily evaluate zero
>
> src/java.base/share/classes/java/util/Formatter.java line 2447:
>
>> 2445: private char zero() {
>> 2446: char zero = this.zero;
>> 2447: if (zero == 0) {
>
> U+ is a valid character. Although it's almost no possibility where any
> locale assigns it as the zero in it, theoretically it is possible. It can be
> avoided by comparing it with a non-character, such as BOM (U+FFFE)
Ok, maybe a bit too defensive, but let's use BOM instead.
-
PR: https://git.openjdk.java.net/jdk/pull/2830
RFR: 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable
Hi, Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable? Kind regards, Patrick - Commit messages: - 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable Changes: https://git.openjdk.java.net/jdk/pull/2879/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2879=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263190 Stats: 60 lines in 15 files changed: 0 ins; 27 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/2879.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2879/head:pull/2879 PR: https://git.openjdk.java.net/jdk/pull/2879
Re: RFR: 8263038: Optimize String.format for simple specifiers [v3]
> This patch optimizes String.format expressions that uses trivial specifiers.
> In the JDK, the most common variation of String.format is a variation of
> format("foo: %s", s), which gets a significant speed-up from this.
>
> Various other cleanups and minor improvements reduce overhead further and
> ensure we get a small gain also for more complex format strings.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Use a BOM as a sentinel for uninitialized zero
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/2830/files
- new: https://git.openjdk.java.net/jdk/pull/2830/files/834450dc..c0a7f911
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk=2830=02
- incr: https://webrevs.openjdk.java.net/?repo=jdk=2830=01-02
Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod
Patch: https://git.openjdk.java.net/jdk/pull/2830.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/2830/head:pull/2830
PR: https://git.openjdk.java.net/jdk/pull/2830
Re: RFR: JDK-8248904: Add support to jpackage for the Mac App Store
On Wed, 24 Feb 2021 21:59:22 GMT, Andy Herrick wrote: > Implementation of Mac App Support including three new mac specific CLI > options. Marked as reviewed by asemenyuk (Committer). - PR: https://git.openjdk.java.net/jdk/pull/2716
Re: RFR: 8263038: Optimize String.format for simple specifiers [v2]
On Mon, 8 Mar 2021 16:00:27 GMT, Claes Redestad wrote:
>> This patch optimizes String.format expressions that uses trivial specifiers.
>> In the JDK, the most common variation of String.format is a variation of
>> format("foo: %s", s), which gets a significant speed-up from this.
>>
>> Various other cleanups and minor improvements reduce overhead further and
>> ensure we get a small gain also for more complex format strings.
>
> Claes Redestad has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Lazily evaluate zero
src/java.base/share/classes/java/util/Formatter.java line 2447:
> 2445: private char zero() {
> 2446: char zero = this.zero;
> 2447: if (zero == 0) {
U+ is a valid character. Although it's almost no possibility where any
locale assigns it as the zero in it, theoretically it is possible. It can be
avoided by comparing it with a non-character, such as BOM (U+FFFE)
-
PR: https://git.openjdk.java.net/jdk/pull/2830
RFR: JDK-8248904: Add support to jpackage for the Mac App Store
Implementation of Mac App Support including three new mac specific CLI options. - Commit messages: - JDK-8248904: Add support for Mac App Store - JDK-8248904: Add support for Mac App Store - JDK-8248904: Add support for Mac App Store - JDK-8248904: Add support for Mac App Store - JDK-8248904: Add support for Mac App Store - JDK-8248904: Add support for Mac App Store Changes: https://git.openjdk.java.net/jdk/pull/2716/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2716=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248904 Stats: 310 lines in 23 files changed: 205 ins; 41 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/2716.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2716/head:pull/2716 PR: https://git.openjdk.java.net/jdk/pull/2716
Re: RFR: 8263038: Optimize String.format for simple specifiers [v2]
On Mon, 8 Mar 2021 16:00:27 GMT, Claes Redestad wrote:
>> This patch optimizes String.format expressions that uses trivial specifiers.
>> In the JDK, the most common variation of String.format is a variation of
>> format("foo: %s", s), which gets a significant speed-up from this.
>>
>> Various other cleanups and minor improvements reduce overhead further and
>> ensure we get a small gain also for more complex format strings.
>
> Claes Redestad has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Lazily evaluate zero
Marked as reviewed by rriggs (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/2830
Re: RFR: 8263038: Optimize String.format for simple specifiers [v2]
On Fri, 5 Mar 2021 16:36:19 GMT, Roger Riggs wrote: >> Claes Redestad has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Lazily evaluate zero > > Looks good. Piling on another optimization: The `getZero(..)` called eagerly in the constructor is rather expensive in non-US locales, e.g. running with "-Duser.language=fr": Benchmark Mode CntScore Error Units StringFormat.stringFormat avgt5 924.536 ± 253.151 ns/op Since the zero value is only used when printing floating point number I refactored so that the localized zero is evaluated lazily, which gets numbers on the micros in line with the numbers for a US locale: Benchmark Mode CntScoreError Units StringFormat.stringFormat avgt5 291.385 ± 64.626 ns/op - PR: https://git.openjdk.java.net/jdk/pull/2830
Re: RFR: 8263038: Optimize String.format for simple specifiers [v2]
> This patch optimizes String.format expressions that uses trivial specifiers.
> In the JDK, the most common variation of String.format is a variation of
> format("foo: %s", s), which gets a significant speed-up from this.
>
> Various other cleanups and minor improvements reduce overhead further and
> ensure we get a small gain also for more complex format strings.
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
Lazily evaluate zero
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/2830/files
- new: https://git.openjdk.java.net/jdk/pull/2830/files/0af863e8..834450dc
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk=2830=01
- incr: https://webrevs.openjdk.java.net/?repo=jdk=2830=00-01
Stats: 13 lines in 1 file changed: 4 ins; 1 del; 8 mod
Patch: https://git.openjdk.java.net/jdk/pull/2830.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/2830/head:pull/2830
PR: https://git.openjdk.java.net/jdk/pull/2830
Re: RFR: 8263038: Optimize String.format for simple specifiers
On Mon, 8 Mar 2021 12:10:24 GMT, Claes Redestad wrote: >> I only looked at it because of the updates to use switch expressions... >> ok, either way. > > I had reason to muck around with the switch expressions, since > `Conversion.isValid` was inefficient (for startup) and subtly wrong (accepted > `'t'`). > > Getting rid of explicit unboxing - `.byteValue()` - is just a syntactic > improvement, so I indulged in a few places. > > Using instanceof pattern matching OTOH changes bytecode shape a fair bit by > introducing locals and changing the execution order. The suggestions you made > above also mean we'd unbox twice. Probably inconsequential, but I'm wary of > such changes when I don't have benchmarks to assert they are performance > neutral. Makes sense, good to know... slick language features *may* come at a cost. - PR: https://git.openjdk.java.net/jdk/pull/2830
Re: Question about java.system.class.loader and the module system
On 03/03/2021 20:12, Volker Simonis wrote: : Maybe I should have been more specific. I meant that the paragraph on "java.system.class.loader" should contain one more sentence mentioning that setting it will only have the desired effects for the loading of application classes for non-modularized applications. "... and is typically the class loader used to start the application" is correct is that it will almost always be the defining class loader of the main class, even if it is loaded from a named module. The combination of -m and -Djava.system.class.loader= should be rare. If there is a compelling need then we could add another sentence to the @implNote to document that the java launcher uses the system class loader when loading the main class from the class path, it is not used when -m is specified. -Alan
Re: RFR: 8263038: Optimize String.format for simple specifiers
On Fri, 5 Mar 2021 17:08:28 GMT, Roger Riggs wrote: >> I did think about it, but it seemed to stray a bit too far from the intent >> of this enhancement. > > I only looked at it because of the updates to use switch expressions... > ok, either way. I had reason to muck around with the switch expressions, since `Conversion.isValid` was inefficient (for startup) and subtly wrong (accepted `'t'`). Getting rid of explicit unboxing - `.byteValue()` - is just a syntactic improvement, so I indulged in a few places. Using instanceof pattern matching OTOH changes bytecode shape a fair bit by introducing locals and changing the execution order. The suggestions you made above also mean we'd unbox twice. Probably inconsequential, but I'm wary of such changes when I don't have benchmarks to assert they are performance neutral. - PR: https://git.openjdk.java.net/jdk/pull/2830
Integrated: 8263090: Avoid reading volatile fields twice in Locale.getDefault(Category)
On Fri, 5 Mar 2021 14:14:14 GMT, Claes Redestad wrote: > This patch refactors Locale.getDefault(Category) so that the volatile field > holding the Locale is typically only read once. This has a small performance > advantage, and might be more robust if initialization is racy. This pull request has now been integrated. Changeset: 13625beb Author:Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/13625beb Stats: 92 lines in 2 files changed: 72 ins; 5 del; 15 mod 8263090: Avoid reading volatile fields twice in Locale.getDefault(Category) Reviewed-by: rriggs, naoto, serb - PR: https://git.openjdk.java.net/jdk/pull/2845
Comment on CSR 8251991: Hex formatting and parsing utility
Hello, it appears that all of the following API methods in [1] can be declared *static*, which makes them more useful in contexts where there's no instance of HexFormat available or none is desired. As 17 has not yet entered any formal phase, the change should be harmless. public boolean isHexDigit(int); public int fromHexDigit(int); public int fromHexDigits(java.lang.CharSequence); public int fromHexDigits(java.lang.CharSequence, int, int); public long fromHexDigitsToLong(java.lang.CharSequence); public long fromHexDigitsToLong(java.lang.CharSequence, int, int); Greetings Raffaello [1] https://bugs.openjdk.java.net/browse/JDK-8251991
Integrated: 8263091: Remove CharacterData.isOtherUppercase/-Lowercase
On Fri, 5 Mar 2021 14:24:34 GMT, Claes Redestad wrote: > This patch removes the CharacterData.isOtherUppercase and isOtherLowercase > methods. It also exploits the fact that isOtherUppercase is always false for > all codepoints in the CharacterDataLatin1 range for a small speed-up. > > I have no means to test if this is correct on PPC, which has intrinsics for > isLowerCase/isUpperCase, but unless I'm reading the code wrong the intrinsic > for isLowerCase on PPC already appears to effectively do the fused logic of > isLowerCase(ch) || isOtherLowerCase(ch) since it handles the two values where > isLowerCase and isOtherLowercase disagrees (0xaa, 0xba), which means this > change should make the intrinsic and the java code be in better agreement. This pull request has now been integrated. Changeset: a0c3f242 Author:Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/a0c3f242 Stats: 98 lines in 8 files changed: 1 ins; 71 del; 26 mod 8263091: Remove CharacterData.isOtherUppercase/-Lowercase Reviewed-by: rriggs, naoto, iris - PR: https://git.openjdk.java.net/jdk/pull/2846
Re: RFR: 8261366: Add discussion of IEEE 754 to BigDecimal
On Mon, 8 Mar 2021 07:23:25 GMT, Joe Darcy wrote:
> Informative update to BigDecimal and related classes to latest IEEE 754
> terminology, including a discussion of the similarities and differences of
> BigDecimal and IEEE 754 decimal arithmetic.
>
> Once the wording is finalized, I'll reflow any modified paragraphs and update
> the copyright years, etc.
src/java.base/share/classes/java/math/BigDecimal.java line 250:
> 248: * values of a given format and produce a result in the same format.
> 249: * A {@code BigDecimal}'s {@linkplain scale() scale} is equivalent to
> 250: * negating an IEEE 754 value's exponent. {@code BigDecimal} values to
_to_ -> _do_
src/java.base/share/classes/java/math/BigDecimal.java line 260:
> 258: * in {@code BigDecimal}, if a nonzero three-digit number and a
> 259: * nonzero four-digit number are multiplied together in the context of
> 260: * a {@code MathContext} object has a precision of three, the result
_has_ -> _having_
src/java.base/share/classes/java/math/BigDecimal.java line 275:
> 273: * numerical values computed can differ if the exponent range of the
> 274: * IEEE 754 format being approximated is exceeded since a {@code
> 275: * MathContext} does not curtail the scale {@code BigDecimal}
_the scale_ -> _the scale of_
Suggest using another word than _curtail_, whose meaning will not be
immediately clear to non-native readers as it's not a technical term.
src/java.base/share/classes/java/math/BigDecimal.java line 277:
> 275: * MathContext} does not curtail the scale {@code BigDecimal}
> 276: * results. Operations that would generate a NaN or exact infinity,
> 277: * such as dividing by zero, throw an {@code Arithmetic-Exception} in
`Arithmetic-Exception` -> `ArithmeticException`
-
PR: https://git.openjdk.java.net/jdk/pull/2868
