[jdk23] RFR: 8334708: FFM: two javadoc problems
Hi all, This pull request contains a backport of commit [72ca7baf](https://github.com/openjdk/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Hannes Greule on 22 Jun 2024 and was reviewed by Maurizio Cimadamore. Thanks! - Commit messages: - Backport 72ca7bafcd49a98c1fe09da72e4e47683f052e9d Changes: https://git.openjdk.org/jdk/pull/19846/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19846&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334708 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19846.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19846/head:pull/19846 PR: https://git.openjdk.org/jdk/pull/19846
Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v5]
On Sat, 22 Jun 2024 21:12:36 GMT, fabioromano1 wrote: >> I have implemented the Zimmermann's square root algorithm, available in >> works [here](https://inria.hal.science/inria-00072854/en/) and >> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). >> >> The algorithm is proved to be asymptotically faster than the Newton's >> Method, even for small numbers. To get an idea of how much the Newton's >> Method is slow, consult my article >> [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method >> with a version of classical square root algorithm that I implemented. After >> implementing Zimmermann's algorithm, it turns out that it is faster than my >> algorithm even for small numbers. > > fabioromano1 has updated the pull request incrementally with one additional > commit since the last revision: > > Removed unused import Thanks for contributing to the OpenJDK! What tests did you run for this change? How did you compare the performance of the new vs the original method? How can we reproduce the results? Please add a JMH benchmark for your changes. JMH benchmarks are the standard method of evaluating performance improvements. - Changes requested by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19710#pullrequestreview-2134108121
Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v5]
On Tue, 18 Jun 2024 15:34:16 GMT, fabioromano1 wrote:
>> fabioromano1 has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed unused import
>
> src/java.base/share/classes/java/math/MutableBigInteger.java line 293:
>
>> 291: */
>> 292: private int compareShifted(MutableBigInteger b, int ints) {
>> 293: this.normalize();
>
> See
> [JDK-8334483](http://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8334483)
It is the responsibility of the caller to ensure that the parameters are
normalized. Calling normalize isn't free, and it's usually easy to tell when a
number needs to be normalized.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1649935313
Re: [jdk23] RFR: 8334441: Mark tests in jdk_security_infra group as manual
On Sat, 22 Jun 2024 08:07:54 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit > [8e1d2b09](https://github.com/openjdk/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Rajan Halade on 21 Jun 2024 and > was reviewed by Christoph Langer and Sean Mullan. > > Thanks! Thanks for the review. - PR Comment: https://git.openjdk.org/jdk/pull/19841#issuecomment-2184269585
Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v5]
> I have implemented the Zimmermann's square root algorithm, available in works > [here](https://inria.hal.science/inria-00072854/en/) and > [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, > even for small numbers. To get an idea of how much the Newton's Method is > slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which > I compare Newton's Method with a version of classical square root algorithm > that I implemented. After implementing Zimmermann's algorithm, it turns out > that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Removed unused import - Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/7ea50cc8..9a3bdc2c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710
Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v4]
> I have implemented the Zimmermann's square root algorithm, available in works > [here](https://inria.hal.science/inria-00072854/en/) and > [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, > even for small numbers. To get an idea of how much the Newton's Method is > slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which > I compare Newton's Method with a version of classical square root algorithm > that I implemented. After implementing Zimmermann's algorithm, it turns out > that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Simplification of code - Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/54fc5fee..7ea50cc8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=02-03 Stats: 29 lines in 1 file changed: 19 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710
Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v3]
> I have implemented the Zimmermann's square root algorithm, available in works > [here](https://inria.hal.science/inria-00072854/en/) and > [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, > even for small numbers. To get an idea of how much the Newton's Method is > slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which > I compare Newton's Method with a version of classical square root algorithm > that I implemented. After implementing Zimmermann's algorithm, it turns out > that it is faster than my algorithm even for small numbers. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Special cases and base case optimization - Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/ddd6d736..54fc5fee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=01-02 Stats: 47 lines in 1 file changed: 18 ins; 10 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710
Withdrawn: 8327791: Optimization for new BigDecimal(String)
On Sun, 10 Mar 2024 16:11:12 GMT, Shaojin Wen wrote:
> The current BigDecimal(String) constructor calls String#toCharArray, which
> has a memory allocation.
>
>
> public BigDecimal(String val) {
> this(val.toCharArray(), 0, val.length()); // allocate char[]
> }
>
>
> When the length is greater than 18, create a char[]
>
>
> boolean isCompact = (len <= MAX_COMPACT_DIGITS); // 18
> if (!isCompact) {
> // ...
> } else {
> char[] coeff = new char[len]; // allocate char[]
> // ...
> }
>
>
> This PR eliminates the two memory allocations mentioned above, resulting in
> an approximate 60% increase in performance..
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/18177
Re: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v3]
On Wed, 3 Apr 2024 16:17:57 GMT, ExE Boss wrote: >> Jan Lahoda has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains six commits: >> >> - Reflecting review feedback. >> - Merge branch 'master' into JDK-8291966 >> - Adding comments >> - Improving performance >> - Merge branch 'master' into JDK-8291966 >> - 8291966: SwitchBootstrap.typeSwitch could be faster > > src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 389: > >> 387: } >> 388: } >> 389: return enumMap.map[value.ordinal()]; > > `enumMap.map` never gets set before this line. There's a bug filed for this already: https://bugs.openjdk.org/browse/JDK-8332522 @lahodaj explained that this broken code is part of an optimization which is never attempted (IIRC due to the bug you noted on line 327). JDK-833522 seem like a good place to continue this conversation..? - PR Review Comment: https://git.openjdk.org/jdk/pull/9779#discussion_r1649761928
Re: [jdk23] RFR: 8334441: Mark tests in jdk_security_infra group as manual
On Sat, 22 Jun 2024 08:07:54 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit > [8e1d2b09](https://github.com/openjdk/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a) > from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Rajan Halade on 21 Jun 2024 and > was reviewed by Christoph Langer and Sean Mullan. > > Thanks! Thanks for doing the backport. - Marked as reviewed by clanger (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19841#pullrequestreview-2133855195
Re: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v3]
On Mon, 29 May 2023 07:25:26 GMT, Jan Lahoda wrote:
>> The pattern matching switches are using a bootstrap method
>> `SwitchBootstrap.typeSwitch` to implement the jumps in the switch.
>> Basically, for a switch like:
>>
>> switch (obj) {
>> case String s when s.isEmpty() -> {}
>> case String s -> {}
>> case CharSequence cs -> {}
>> ...
>> }
>>
>>
>> this method will produce a MethodHandle that will be analyze the provided
>> selector value (`obj` in the example), and will return the case index to
>> which the switch should jump. This method also accepts a (re)start index for
>> the search, which is used to handle guards. For example, if the
>> `s.isEmpty()` guard in the above sample returns false, the matching is
>> restarted on the next case.
>>
>> The current implementation is fairly slow, it basically goes through the
>> labels in a loop. The proposal here is to replace that with a MethodHandle
>> structure like this:
>>
>> obj == null ? -1
>> : switch (restartIndex) {
>> case 0 -> obj instanceof String ? 0 : obj instanceof
>> CharSequence ? 2 : ... ;
>> case 1 -> obj instanceof String ? 1 : obj instanceof
>> CharSequence ? 2 : ... ;
>> case 2 -> obj instanceof CharSequence ? 2 : ... ;
>> ...
>> default -> ;
>> }
>>
>>
>> This appear to run faster than the current implementation, using testcase
>> similar to the one used for https://github.com/openjdk/jdk/pull/9746 , these
>> are the results
>>
>> PatternsOptimizationTest.testLegacyIndyLongSwitch thrpt 25 1515989.562
>> ± 32047.918 ops/s
>> PatternsOptimizationTest.testHandleIndyLongSwitch thrpt 25 2630707.585
>> ± 37202.210 ops/s
>>
>> PatternsOptimizationTest.testLegacyIndyShortSwitch thrpt 25 6789310.900
>> ± 61921.636 ops/s
>> PatternsOptimizationTest.testHandleIndyShortSwitch thrpt 25 10771729.464
>> ± 69607.467 ops/s
>>
>>
>> The "LegacyIndy" is the current implementation, "HandleIndy" is the one
>> proposed here. The translation in javac used is the one from #9746 in all
>> cases.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge
> or a rebase. The pull request now contains six commits:
>
> - Reflecting review feedback.
> - Merge branch 'master' into JDK-8291966
> - Adding comments
> - Improving performance
> - Merge branch 'master' into JDK-8291966
> - 8291966: SwitchBootstrap.typeSwitch could be faster
Changes requested by exe-b...@github.com (no known OpenJDK username).
src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 327:
> 325:
> 326: MethodHandle target;
> 327: boolean constantsOnly = Stream.of(labels).allMatch(l ->
> enumClass.isAssignableFrom(EnumDesc.class));
This expression is always false, it should be:
Suggestion:
boolean constantsOnly = Stream.of(labels).allMatch(l ->
l.isAssignableFrom(EnumDesc.class));
-
PR Review: https://git.openjdk.org/jdk/pull/9779#pullrequestreview-2133851725
PR Review Comment: https://git.openjdk.org/jdk/pull/9779#discussion_r1649740572
Re: RFR: 8307818: Convert Indify tool to Classfile API [v16]
> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code > private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, > MethodType, and CallSite constants. > It currently uses ad-hoc code to process class files and intends to migrate > to ASM; but since we have the Classfile API, we can migrate to Classfile API > instead. Oussama Louati has updated the pull request incrementally with one additional commit since the last revision: remove: removed unnecessary logging - Changes: - all: https://git.openjdk.org/jdk/pull/18841/files - new: https://git.openjdk.org/jdk/pull/18841/files/c5a08302..02347415 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/18841.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841 PR: https://git.openjdk.org/jdk/pull/18841
Re: RFR: 8307818: Convert Indify tool to Classfile API [v15]
> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code > private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, > MethodType, and CallSite constants. > It currently uses ad-hoc code to process class files and intends to migrate > to ASM; but since we have the Classfile API, we can migrate to Classfile API > instead. Oussama Louati has updated the pull request incrementally with one additional commit since the last revision: fix: review addressing - Changes: - all: https://git.openjdk.org/jdk/pull/18841/files - new: https://git.openjdk.org/jdk/pull/18841/files/03ec3ed6..c5a08302 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=13-14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18841.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841 PR: https://git.openjdk.org/jdk/pull/18841
Re: RFR: 8307818: Convert Indify tool to Classfile API [v14]
> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code > private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, > MethodType, and CallSite constants. > It currently uses ad-hoc code to process class files and intends to migrate > to ASM; but since we have the Classfile API, we can migrate to Classfile API > instead. Oussama Louati has updated the pull request incrementally with one additional commit since the last revision: fix: review addressing - Changes: - all: https://git.openjdk.org/jdk/pull/18841/files - new: https://git.openjdk.org/jdk/pull/18841/files/f80fd483..03ec3ed6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=12-13 Stats: 53 lines in 1 file changed: 2 ins; 16 del; 35 mod Patch: https://git.openjdk.org/jdk/pull/18841.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841 PR: https://git.openjdk.org/jdk/pull/18841
Re: RFR: 8307818: Convert Indify tool to Classfile API [v13]
On Sat, 22 Jun 2024 09:39:46 GMT, Oussama Louati wrote:
>> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code
>> private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle,
>> MethodType, and CallSite constants.
>> It currently uses ad-hoc code to process class files and intends to migrate
>> to ASM; but since we have the Classfile API, we can migrate to Classfile API
>> instead.
>
> Oussama Louati has updated the pull request incrementally with six additional
> commits since the last revision:
>
> - Update test/jdk/java/lang/invoke/indify/Indify.java
>
>Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
> - Update test/jdk/java/lang/invoke/indify/Indify.java
>
>Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
> - Update test/jdk/java/lang/invoke/indify/Indify.java
>
>Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
> - Update test/jdk/java/lang/invoke/indify/Indify.java
>
>Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
> - Update test/jdk/java/lang/invoke/indify/Indify.java
>
>Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com>
> - fix: work done
test/jdk/java/lang/invoke/indify/Indify.java line 378:
> 376:
> 377: void writeNewClassFile(ClassModel newClassModel, Boolean changed,
> File sourceFile) throws IOException {
> 378: byte[] new_bytes = transformToBytes(newClassModel);
`newBytes`
test/jdk/java/lang/invoke/indify/Indify.java line 379:
> 377: void writeNewClassFile(ClassModel newClassModel, Boolean changed,
> File sourceFile) throws IOException {
> 378: byte[] new_bytes = transformToBytes(newClassModel);
> 379: if(changed || all){
If you are using idea, select this whole method body and run ctrl+alt+L to
format the code. A few improper formatting.
test/jdk/java/lang/invoke/indify/Indify.java line 478:
> 476: Logic logic = new Logic(model);
> 477: Boolean changed = logic.transform();
> 478: if (verbose && changed) System.err.println("(no change)");
Suggestion:
if (verbose && !changed) System.err.println("(no change)");
test/jdk/java/lang/invoke/indify/Indify.java line 480:
> 478: if (verbose && changed) System.err.println("(no change)");
> 479: logic.reportPatternMethods(!verbose, keepgoing);
> 480: byte[] new_Bytes = transformToBytes(logic.classModel);
`newBytes`
test/jdk/java/lang/invoke/indify/Indify.java line 501:
> 499: if (!findPatternMethods()) return false;
> 500:
> 501: Stack pendingIndy = new Stack<>(); // stack to
> hold the pending invokedynamic constant to replace the invokeExact
Please use `Deque` and `ArrayDeque` instead.
test/jdk/java/lang/invoke/indify/Indify.java line 536:
> 534: pendingIndy.push(newConstant);
> 535: if (!quiet) {
> 536: System.err.println(":::Transforming the
> Method Class for: " + ((InvokeInstruction) e).method().name() +
Suggestion:
System.err.println(":::Transforming the Method
Class for: " + invokeInstruction.method().name() +
test/jdk/java/lang/invoke/indify/Indify.java line 545:
> 543: } else {
> 544: if (!quiet) {
> 545: System.err.println(":::Transforming the
> Method Call of: " + ((InvokeInstruction) e).method().name() +
Suggestion:
System.err.println(":::Transforming the Method Call
of: " + invokeInstruction.method().name() +
-
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649697535
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649697624
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649697501
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649697679
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649698078
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649699193
PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649699115
Integrated: 8334708: FFM: two javadoc problems
On Fri, 21 Jun 2024 07:40:31 GMT, Hannes Greule wrote: > Addresses two simple problems regarding javadocs in the FFM API. This pull request has now been integrated. Changeset: 72ca7baf Author:Hannes Greule Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8334708: FFM: two javadoc problems Reviewed-by: mcimadamore - PR: https://git.openjdk.org/jdk/pull/19820
Re: RFR: 8307818: Convert Indify tool to Classfile API [v13]
On Mon, 17 Jun 2024 08:33:17 GMT, Adam Sotona wrote: >> We need a boolean value to determine if we should proceed after replacing >> the appropriate "pop" instruction with an "invokedynamic" instruction. >> However, instead of using just a boolean field, we use a stack. The reason >> for this is that within the lambda expression, we can only use final >> variables. By using a stack, we can update its value as needed, which is why >> this approach is chosen. > > I see here an iteration over instructions of a method, where the whole class > is retransformed in certain situations and some status is passed back in a > stack of booleans. > The whole conversion should be implemented in a single transformation. > Original code repeatedly replaced instructions inline (that is BTW reason why > added nops below), however architecture of ClassFile API is different, you > are transforming one class into completely new class (free to remove and add > as many elements as you need). You can compose transformations into complex > trees and you can also collect information before the transformation, however > the class transformation should be executed only once. Done. The code has been refactored to perform the transformation in one go. - PR Review Comment: https://git.openjdk.org/jdk/pull/18841#discussion_r1649620002
Re: RFR: 8307818: Convert Indify tool to Classfile API [v13]
> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code > private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, > MethodType, and CallSite constants. > It currently uses ad-hoc code to process class files and intends to migrate > to ASM; but since we have the Classfile API, we can migrate to Classfile API > instead. Oussama Louati has updated the pull request incrementally with six additional commits since the last revision: - Update test/jdk/java/lang/invoke/indify/Indify.java Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com> - Update test/jdk/java/lang/invoke/indify/Indify.java Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com> - Update test/jdk/java/lang/invoke/indify/Indify.java Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com> - Update test/jdk/java/lang/invoke/indify/Indify.java Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com> - Update test/jdk/java/lang/invoke/indify/Indify.java Co-authored-by: ExE Boss <3889017+exe-b...@users.noreply.github.com> - fix: work done - Changes: - all: https://git.openjdk.org/jdk/pull/18841/files - new: https://git.openjdk.org/jdk/pull/18841/files/7e928ced..f80fd483 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=11-12 Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/18841.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841 PR: https://git.openjdk.org/jdk/pull/18841
Re: RFR: 8307818: Convert Indify tool to Classfile API [v12]
> An indify tool in j.l.i tests (also in vmTestBase) convert some source-code > private static methods with MT_ MH_, and INDY_ prefixes into MethodHandle, > MethodType, and CallSite constants. > It currently uses ad-hoc code to process class files and intends to migrate > to ASM; but since we have the Classfile API, we can migrate to Classfile API > instead. Oussama Louati has updated the pull request incrementally with eight additional commits since the last revision: - fix: work done - fix: work in progress - fix: one pass transformation per method - fix: one pass transformation per method - fix: one pass transformation per method - fix: fixing - commit before disaster - fix: remove adding NOPS into method instruction - Changes: - all: https://git.openjdk.org/jdk/pull/18841/files - new: https://git.openjdk.org/jdk/pull/18841/files/f869cce8..7e928ced Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18841&range=10-11 Stats: 112 lines in 1 file changed: 15 ins; 53 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/18841.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18841/head:pull/18841 PR: https://git.openjdk.org/jdk/pull/18841
Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm [v2]
> I have implemented the Zimmermann's square root algorithm, available in works > [here](https://inria.hal.science/inria-00072854/en/) and > [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). > > The algorithm is proved to be asymptotically faster than the Newton's Method, > even for small numbers. To get an idea of how much the Newton's Method is > slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which > I compare Newton's Method with a version of classical square root algorithm > that I implemented. After implementing Zimmermann's algorithm, it turns out > that it is faster than my algorithm even for small numbers. fabioromano1 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 29 additional commits since the last revision: - Inserted author - Merge branch 'openjdk:master' into patchSqrt - Merge branch 'openjdk:master' into patchSqrt - An optimization - Merge branch 'patchSqrt' of https://github.com/fabioromano1/jdk into patchSqrt - Merge branch 'openjdk:master' into patchSqrt - An optimization - An optimization - Optimized memory usage of square root algorithm - An optimization - ... and 19 more: https://git.openjdk.org/jdk/compare/4ba48068...ddd6d736 - Changes: - all: https://git.openjdk.org/jdk/pull/19710/files - new: https://git.openjdk.org/jdk/pull/19710/files/d95f9e7f..ddd6d736 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=00-01 Stats: 18281 lines in 220 files changed: 12473 ins; 4295 del; 1513 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710
Re: RFR: 8334755: Asymptotically faster implementation of square root algorithm
On Thu, 13 Jun 2024 18:31:33 GMT, fabioromano1 wrote:
> I have implemented the Zimmermann's square root algorithm, available in works
> [here](https://inria.hal.science/inria-00072854/en/) and
> [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root).
>
> The algorithm is proved to be asymptotically faster than the Newton's Method,
> even for small numbers. To get an idea of how much the Newton's Method is
> slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which
> I compare Newton's Method with a version of classical square root algorithm
> that I implemented. After implementing Zimmermann's algorithm, it turns out
> that it is faster than my algorithm even for small numbers.
src/java.base/share/classes/java/math/MutableBigInteger.java line 265:
> 263: */
> 264: final int compare(MutableBigInteger b) {
> 265: this.normalize();
See [JDK-8334483](http://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8334483)
src/java.base/share/classes/java/math/MutableBigInteger.java line 293:
> 291: */
> 292: private int compareShifted(MutableBigInteger b, int ints) {
> 293: this.normalize();
See [JDK-8334483](http://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8334483)
src/java.base/share/classes/java/math/MutableBigInteger.java line 826:
> 824: while (x > 0 && y > 0) {
> 825: x--; y--;
> 826: int bval = y < addend.intLen ? addend.value[y+addend.offset]
> : 0;
See [JDK-8334434](https://bugs.openjdk.org/browse/JDK-8334434)
src/java.base/share/classes/java/math/MutableBigInteger.java line 897:
> 895: rstart -= x;
> 896:
> 897: int len = Math.min(y, addend.intLen);
See [JDK-8334434](https://bugs.openjdk.org/browse/JDK-8334434)
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1644669348
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1644669676
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1644037011
PR Review Comment: https://git.openjdk.org/jdk/pull/19710#discussion_r1644037695
RFR: 8334755: Asymptotically faster implementation of square root algorithm
I have implemented the Zimmermann's square root algorithm, available in works [here](https://inria.hal.science/inria-00072854/en/) and [here](https://www.researchgate.net/publication/220532560_A_proof_of_GMP_square_root). The algorithm is proved to be asymptotically faster than the Newton's Method, even for small numbers. To get an idea of how much the Newton's Method is slow, consult my article [here](https://arxiv.org/abs/2406.07751), in which I compare Newton's Method with a version of classical square root algorithm that I implemented. After implementing Zimmermann's algorithm, it turns out that it is faster than my algorithm even for small numbers. - Commit messages: - Merge branch 'openjdk:master' into patchSqrt - An optimization - Merge branch 'patchSqrt' of https://github.com/fabioromano1/jdk into patchSqrt - Merge branch 'openjdk:master' into patchSqrt - An optimization - An optimization - Optimized memory usage of square root algorithm - An optimization - Update comment - Update MutableBigInteger.java - ... and 17 more: https://git.openjdk.org/jdk/compare/50bed6c6...d95f9e7f Changes: https://git.openjdk.org/jdk/pull/19710/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19710&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334755 Stats: 182 lines in 2 files changed: 172 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/19710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19710/head:pull/19710 PR: https://git.openjdk.org/jdk/pull/19710
[jdk23] RFR: 8334441: Mark tests in jdk_security_infra group as manual
Hi all, This pull request contains a backport of commit [8e1d2b09](https://github.com/openjdk/jdk/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Rajan Halade on 21 Jun 2024 and was reviewed by Christoph Langer and Sean Mullan. Thanks! - Commit messages: - Backport 8e1d2b091c9a311d98a0b886a803fb18d4405d8a Changes: https://git.openjdk.org/jdk/pull/19841/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19841&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334441 Stats: 160 lines in 10 files changed: 5 ins; 2 del; 153 mod Patch: https://git.openjdk.org/jdk/pull/19841.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19841/head:pull/19841 PR: https://git.openjdk.org/jdk/pull/19841
