[jdk18] RFR: 8278907: JPackage test - SigningPackageTest is failed with runtime exception
This is regression from JDK-8263155. MacHelper.java is now calling test verification callback with all content in DMG root. SigningPackageTest expects only path with app name in it and thus it fails when trying to verify app inside ".background" folder. Fixed by checking that provided path for verification is actually an application we expecting. All other paths are ignored. - Commit messages: - 8278907: JPackage test - SigningPackageTest is failed with runtime exception Changes: https://git.openjdk.java.net/jdk18/pull/42/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18=42=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278907 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk18/pull/42.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/42/head:pull/42 PR: https://git.openjdk.java.net/jdk18/pull/42
Re: RFR: 8213905: reflection not working for type annotations applied to exception types in the inner class constructor
On Thu, 16 Dec 2021 17:44:04 GMT, Vicente Romero wrote:
> Hi,
>
> Please review this change that is fixing a bug in reflection in particular in
> `sun.reflect.annotation.TypeAnnotationParser::buildAnnotatedTypes` the
> current code is assuming that for inner class constructors it is always
> working on type annotations on parameters, but it is also invoked to extract
> type annotations applied to exception types for example. This bug affects the
> behavior of method:
> `java.lang.reflect.Executable::getAnnotatedExceptionTypes` which is not
> behaving according to its specification. Given that this fix affects the
> behavior of a method belonging to our API a CSR has been filed too. Please
> review it at [JDK-8278926](https://bugs.openjdk.java.net/browse/JDK-8278926).
>
> TIA
src/java.base/share/classes/sun/reflect/annotation/TypeAnnotationParser.java
line 137:
> 135: (declaringClass.getModifiers() & Modifier.STATIC) == 0)
> &&
> 136: filter ==
> TypeAnnotation.TypeAnnotationTarget.METHOD_FORMAL_PARAMETER) {
> 137: offset = true;
Currently, we have a few parallel systems for determining if certain parameters
are synthetic. This guessing by being inner classes or enums is one, and
detecting the flags from `MethodParameters` attribute (used for handling
signatures) is another. (In fact, both are present in `Executable` in
`handleParameterNumberMismatch` and `getAllGenericParameterTypes`)
Detecting `MethodParameters` attribute should be more reliable, especially for
other code that may include methods with any number of synthetic or mandated
parameters (presumably in the beginning of the parameter list). However, javac
will not produce that attribute without `-parameters` flag, so most class files
compiled to be missing this attribute.
IMO a longer-term solution is to opt-in Javac to emit critical method parameter
information by default (ex. emit the parameter flags without names) whenever it
emits parameter signatures or annotations. And then the system for skipping
synthetic/mandated parameters in the two places may possibly be unified.
-
PR: https://git.openjdk.java.net/jdk/pull/6869
Integrated: Merge jdk18
On Fri, 17 Dec 2021 00:05:41 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 18 -> JDK 19 This pull request has now been integrated. Changeset: 634afe8c Author:Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/634afe8c5c0855eafb1639f54ecc8e9c9e568814 Stats: 29 lines in 4 files changed: 12 ins; 1 del; 16 mod Merge - PR: https://git.openjdk.java.net/jdk/pull/6873
[jdk18] Integrated: 8276826: Clarify the ModuleDescriptor.Version specification’s treatment of repeated punctuation characters
On Thu, 16 Dec 2021 22:16:26 GMT, Mark Reinhold wrote: > Please review this tiny specification clarification. This pull request has now been integrated. Changeset: f5d7c777 Author:Mark Reinhold URL: https://git.openjdk.java.net/jdk18/commit/f5d7c777bc516fa2e711c19d5281ebf32384b543 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8276826: Clarify the ModuleDescriptor.Version specification’s treatment of repeated punctuation characters Reviewed-by: mchung, darcy - PR: https://git.openjdk.java.net/jdk18/pull/39
RFR: Merge jdk18
Forwardport JDK 18 -> JDK 19 - Commit messages: - Merge - 8278574: update --help-extra message to include default value of --finalization option - 8278389: SuspendibleThreadSet::_suspend_all should be volatile/atomic - 8278575: update jcmd GC.finalizer_info to list finalization status The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/?repo=jdk=6873=00.0 - jdk18: https://webrevs.openjdk.java.net/?repo=jdk=6873=00.1 Changes: https://git.openjdk.java.net/jdk/pull/6873/files Stats: 29 lines in 4 files changed: 12 ins; 1 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/6873.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6873/head:pull/6873 PR: https://git.openjdk.java.net/jdk/pull/6873
Re: RFR: 8261404: Class.getReflectionFactory() is not thread-safe [v2]
On Thu, 16 Dec 2021 21:38:30 GMT, liach wrote: >> Simply changes this to only read the static field once to prevent `null` on >> second read. > > liach has updated the pull request incrementally with two additional commits > since the last revision: > > - sorry, reintroduced the bug in last patch > - choose a concise name for the local var Marked as reviewed by mchung (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6870
Re: [jdk18] RFR: 8276826: Clarify the ModuleDescriptor.Version specification’s treatment of repeated punctuation characters
On Thu, 16 Dec 2021 22:16:26 GMT, Mark Reinhold wrote: > Please review this tiny specification clarification. Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk18/pull/39
Re: [jdk18] RFR: 8276826: Clarify the ModuleDescriptor.Version specification’s treatment of repeated punctuation characters
On Thu, 16 Dec 2021 22:16:26 GMT, Mark Reinhold wrote: > Please review this tiny specification clarification. Marked as reviewed by mchung (Reviewer). - PR: https://git.openjdk.java.net/jdk18/pull/39
Re: RFR: 8278087: Deserialization filter and filter factory property error reporting under specified [v2]
On Mon, 6 Dec 2021 16:59:41 GMT, Roger Riggs wrote: >> The effects of invalid values of `jdk.serialFilter` and >> `jdk.serialFilterFactory` properties are >> incompletely specified. The behavior for invalid values of the properties is >> different and >> use an unconventional exception type, `ExceptionInInitializerError` and >> leave the `OIF.Config` class >> uninitialized. >> >> The exceptions in the `ObjectInputFilter.Config` class initialization caused >> by invalid values of the two properties, >> either by system properties supplied on the command line or security >> properties are logged. >> The `Config` class marks either or both the filter and filter factory values >> as unusable >> and remembers the exception message. >> >> Subsequent calls to the methods that get or set the filter or filter factory >> or create >> an `ObjectInputStream` throw `java.lang.IllegalStateException` with the >> remembered exception message. >> Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and >> `Config.getSerialFilterFactory`. >> The nature of the invalid property is reported as an `IllegalStateException` >> on first use. >> >> This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that >> setting an invalid property jdk.serialFilter disables deserialization > > Roger Riggs has updated the pull request incrementally with one additional > commit since the last revision: > > Address review comments to consistently identify security property names > and use the correct bug number in the test. Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6645
Re: RFR: 8213905: reflection not working for type annotations applied to exception types in the inner class constructor
On Thu, 16 Dec 2021 18:01:54 GMT, Joe Darcy wrote: > Hi Vicente. > > Please file a CSR for the behavioral change. sure, thanks - PR: https://git.openjdk.java.net/jdk/pull/6869
Re: [jdk18] RFR: 8276826: Clarify the ModuleDescriptor.Version specification’s treatment of repeated punctuation characters
On Thu, 16 Dec 2021 22:16:26 GMT, Mark Reinhold wrote: > Please review this tiny specification clarification. Drat, used the wrong bug id. - PR: https://git.openjdk.java.net/jdk18/pull/39
[jdk18] RFR: 8276826: Clarify the ModuleDescriptor.Version specification’s treatment of repeated punctuation characters
Please review this tiny specification clarification. - Commit messages: - 8278465: Clarify the ModuleDescriptor.Version specification’s treatment of repeated punctuation characters Changes: https://git.openjdk.java.net/jdk18/pull/39/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18=39=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276826 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk18/pull/39.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/39/head:pull/39 PR: https://git.openjdk.java.net/jdk18/pull/39
Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v7]
On Thu, 16 Dec 2021 21:48:14 GMT, kabutz wrote: > > embarrassingly parallelizable > > Having looked at [embarrassingly > parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not > certain that this particular problem would qualify. The algorithm is easy to > parallelize, but in the end we still have some rather large numbers, so > memory will be our primary dominator. I'd expect to see a linear speedup if > it was "perfectly parallel", but this does not come close to that. Ok, fair point, to avoid possible confusion I have removed "embarrassingly". I don't think we need to refer to other algorithms. - PR: https://git.openjdk.java.net/jdk/pull/6409
Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v7]
On Thu, 16 Dec 2021 21:37:26 GMT, kabutz wrote: > > embarrassingly parallelizable > > Having looked at [embarrassingly > parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not > certain that this particular problem would qualify. The algorithm is easy to > parallelize, but in the end we still have some rather large numbers, so > memory will be our primary dominator. I'd expect to see a linear speedup if > it was "perfectly parallel", but this does not come close to that. I ran fibonacci(100_000_000) with multiply() and parallelMultiply(). For multiply() we had: real0m25.627s user0m26.767s sys 0m1.197s and for parallelMultiply() we had real0m10.030s user1m2.205s sys 0m2.489s Thus we are 2.5 times faster on a 1-6-2 machine, but use more than 2x the user time. If it were perfectly parallel, shouldn't we expect to see the parallelMultiply() be close to user time of 26s and real time 4.3s? - PR: https://git.openjdk.java.net/jdk/pull/6409
Re: RFR: 8278044: ObjectInputStream methods invoking the OIF.CFG.getSerialFilterFactory() silent about error cases. [v2]
On Mon, 6 Dec 2021 16:01:43 GMT, Roger Riggs wrote:
>> The specification of ObjectInputStream constructors that invoke
>> `ObjectInputFilter.Config.getSerialFilterFactory()` do not mention
>> exceptions that may be thrown by the apply() method.
>>
>> In both constructors, add the following to the paragraph the describes
>> invoking the factory:
>>
>> * When the filter factory {@code apply} method is invoked it may throw
>> a runtime exception
>> * preventing the {@code ObjectInputStream} from being constructed.
>
> Roger Riggs has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Clarified that a runtime exception may be thrown by the filter factory
> returned from `ObjectInputFilter.Config.getSerialFilterFactory()`
> not by the `getSerialFilterFactory` method.
Marked as reviewed by bpb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6704
Integrated: 8278587: StringTokenizer(String, String, boolean) documentation bug
On Tue, 14 Dec 2021 18:25:45 GMT, Naoto Sato wrote: > This is a doc fix to `StringTokenizer`, where the original spec does not > account for the delimiter's length in the case of a supplementary character. > Corresponding CSR has been drafted: > https://bugs.openjdk.java.net/browse/JDK-8278814 This pull request has now been integrated. Changeset: 8f5fdd86 Author:Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/8f5fdd864b6f1cf4a2d9d961d8d4118960f0751e Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod 8278587: StringTokenizer(String, String, boolean) documentation bug Reviewed-by: iris, joehw, lancea, rriggs, darcy - PR: https://git.openjdk.java.net/jdk/pull/6836
Integrated: 8277868: Use Comparable.compare() instead of surrogate code
On Fri, 26 Nov 2021 12:46:59 GMT, Сергей Цыпанов wrote: > Instead of something like > > long x; > long y; > return (x < y) ? -1 : ((x == y) ? 0 : 1); > > we can use `return Long.compare(x, y);` > > All replacements are done with IDE. This pull request has now been integrated. Changeset: 20db7800 Author:Sergey Tsypanov Committer: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/20db7800a657b311eeac504a2bbae4adbc209dbf Stats: 77 lines in 12 files changed: 2 ins; 54 del; 21 mod 8277868: Use Comparable.compare() instead of surrogate code Reviewed-by: rriggs, aivanov - PR: https://git.openjdk.java.net/jdk/pull/6575
Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v7]
On Thu, 16 Dec 2021 21:30:21 GMT, kabutz wrote: > embarrassingly parallelizable Having looked at [embarrassingly parallel](https://en.wikipedia.org/wiki/Embarrassingly_parallel), I'm not certain that this particular problem would qualify. The algorithm is easy to parallelize, but in the end we still have some rather large numbers, so memory will be our primary dominator. I'd expect to see a linear speedup if it was "perfectly parallel", but this does not come close to that. - PR: https://git.openjdk.java.net/jdk/pull/6409
Re: RFR: 8261404: Class.getReflectionFactory() is not thread-safe [v2]
> Simply changes this to only read the static field once to prevent `null` on > second read. liach has updated the pull request incrementally with two additional commits since the last revision: - sorry, reintroduced the bug in last patch - choose a concise name for the local var - Changes: - all: https://git.openjdk.java.net/jdk/pull/6870/files - new: https://git.openjdk.java.net/jdk/pull/6870/files/2f7c84a1..acc043ee Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6870=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6870=00-01 Stats: 8 lines in 1 file changed: 2 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6870.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6870/head:pull/6870 PR: https://git.openjdk.java.net/jdk/pull/6870
Re: RFR: 8261404: Class.getReflectionFactory() is not thread-safe
On Thu, 16 Dec 2021 21:04:58 GMT, liach wrote:
> Simply changes this to only read the static field once to prevent `null` on
> second read.
src/java.base/share/classes/java/lang/Class.java line 3828:
> 3826: java.security.AccessController.doPrivileged
> 3827: (new
> ReflectionFactory.GetReflectionFactoryAction());
> 3828: }
p.s. If using an early return, I'd have it return early in the case
reflectionFactory was not-null.
then fall through to compute and assign the factory and return it.
var factory = reflectionFactory;
if (factory != null) {
return factory;
}
return reflectionFactory =
java.security.AccessController.doPrivileged
(new ReflectionFactory.GetReflectionFactoryAction());
-
PR: https://git.openjdk.java.net/jdk/pull/6870
Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v7]
On Thu, 16 Dec 2021 21:22:02 GMT, Paul Sandoz wrote: > > "embarrassingly parallel when employing recursive" -> "embarrassingly > > non-parallel when employing recursive" (?) > > I corrected to "embarrassingly parallelizable" (i believe that is a common > phrase we as software engineers use in these cases). Makes more sense that way. Should we add something about it not being computationally worthwhile doing for the Karatsuba calculation, which is even easier to parallelize, but which has a lower threshold and thus does not give performance advantages? - PR: https://git.openjdk.java.net/jdk/pull/6409
Re: RFR: 8261404: Class.getReflectionFactory() is not thread-safe
On Thu, 16 Dec 2021 21:04:58 GMT, liach wrote: > Simply changes this to only read the static field once to prevent `null` on > second read. It would be easier to read and clearer if the local was not named the same as the static. - Changes requested by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6870
Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v7]
On Thu, 16 Dec 2021 20:09:59 GMT, kabutz wrote: > "embarrassingly parallel when employing recursive" -> "embarrassingly > non-parallel when employing recursive" (?) I corrected to "embarrassingly parallelizable" (i believe that is a common phrase we as software engineers use in these cases). - PR: https://git.openjdk.java.net/jdk/pull/6409
RFR: 8261404: Class.getReflectionFactory() is not thread-safe
Simply changes this to only read the static field once to prevent `null` on second read. - Commit messages: - 8261404: Class.getReflectionFactory() is not thread-safe Changes: https://git.openjdk.java.net/jdk/pull/6870/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6870=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261404 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6870.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6870/head:pull/6870 PR: https://git.openjdk.java.net/jdk/pull/6870
Re: RFR: 8278087: Deserialization filter and filter factory property error reporting under specified [v2]
On Mon, 6 Dec 2021 16:59:41 GMT, Roger Riggs wrote: >> The effects of invalid values of `jdk.serialFilter` and >> `jdk.serialFilterFactory` properties are >> incompletely specified. The behavior for invalid values of the properties is >> different and >> use an unconventional exception type, `ExceptionInInitializerError` and >> leave the `OIF.Config` class >> uninitialized. >> >> The exceptions in the `ObjectInputFilter.Config` class initialization caused >> by invalid values of the two properties, >> either by system properties supplied on the command line or security >> properties are logged. >> The `Config` class marks either or both the filter and filter factory values >> as unusable >> and remembers the exception message. >> >> Subsequent calls to the methods that get or set the filter or filter factory >> or create >> an `ObjectInputStream` throw `java.lang.IllegalStateException` with the >> remembered exception message. >> Constructing an `ObjectInputStream` calls both `Config.getSerialFilter` and >> `Config.getSerialFilterFactory`. >> The nature of the invalid property is reported as an `IllegalStateException` >> on first use. >> >> This PR supercedes https://github.com/openjdk/jdk/pull/6508 Document that >> setting an invalid property jdk.serialFilter disables deserialization > > Roger Riggs has updated the pull request incrementally with one additional > commit since the last revision: > > Address review comments to consistently identify security property names > and use the correct bug number in the test. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6645
Re: RFR: 8278044: ObjectInputStream methods invoking the OIF.CFG.getSerialFilterFactory() silent about error cases. [v2]
On Mon, 6 Dec 2021 16:01:43 GMT, Roger Riggs wrote:
>> The specification of ObjectInputStream constructors that invoke
>> `ObjectInputFilter.Config.getSerialFilterFactory()` do not mention
>> exceptions that may be thrown by the apply() method.
>>
>> In both constructors, add the following to the paragraph the describes
>> invoking the factory:
>>
>> * When the filter factory {@code apply} method is invoked it may throw
>> a runtime exception
>> * preventing the {@code ObjectInputStream} from being constructed.
>
> Roger Riggs has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Clarified that a runtime exception may be thrown by the filter factory
> returned from `ObjectInputFilter.Config.getSerialFilterFactory()`
> not by the `getSerialFilterFactory` method.
Marked as reviewed by lancea (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6704
Re: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap [v2]
> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` > `merge` would throw CME if the functions modified the map itself, and there > are corresponding specification changes. liach 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 five additional commits since the last revision: - Merge branch 'master' of https://git.openjdk.java.net/jdk into identityhashmap-default - update dates - Also test cme for identity hash map - Fix putIfAbsent - JDK-8277520: Implement JDK-8 default methods for IdentityHashMap - Changes: - all: https://git.openjdk.java.net/jdk/pull/6532/files - new: https://git.openjdk.java.net/jdk/pull/6532/files/e492cb7b..d853ab34 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6532=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6532=00-01 Stats: 57223 lines in 1494 files changed: 36387 ins; 12123 del; 8713 mod Patch: https://git.openjdk.java.net/jdk/pull/6532.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6532/head:pull/6532 PR: https://git.openjdk.java.net/jdk/pull/6532
Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v6]
On Thu, 16 Dec 2021 19:46:19 GMT, Paul Sandoz wrote: > > Terribly sorry to ask this, but where would I see the CSR? I don't have > > access to the JIRA in the backend. > > You should be able to view it but not edit: > > https://bugs.openjdk.java.net/browse/JDK-8278886 > > (To get creation/update access rights you need to become an OpenJDK author.) > > If you have comments/edits the easier approach is to comment on this PR and I > can update. And thank you very much, @PaulSandoz, @jddarcy, @dholmes-ora, @cl4es, @fisk, @bplb, and others on the mailing list for taking the time to review this proposal and to help improve on my original idea :-) - PR: https://git.openjdk.java.net/jdk/pull/6409
Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v7]
On Thu, 16 Dec 2021 06:07:29 GMT, kabutz wrote: >> BigInteger currently uses three different algorithms for multiply. The >> simple quadratic algorithm, then the slightly better Karatsuba if we exceed >> a bit count and then Toom Cook 3 once we go into the several thousands of >> bits. Since Toom Cook 3 is a recursive algorithm, it is trivial to >> parallelize it. I have demonstrated this several times in conference talks. >> In order to be consistent with other classes such as Arrays and Collection, >> I have added a parallelMultiply() method. Internally we have added a >> parameter to the private multiply method to indicate whether the calculation >> should be done in parallel. >> >> The performance improvements are as should be expected. Fibonacci of 100 >> million (using a single-threaded Dijkstra's sum of squares version) >> completes in 9.2 seconds with the parallelMultiply() vs 25.3 seconds with >> the sequential multiply() method. This is on my 1-8-2 laptop. The final >> multiplications are with very large numbers, which then benefit from the >> parallelization of Toom-Cook 3. Fibonacci 100 million is a 347084 bit number. >> >> We have also parallelized the private square() method. Internally, the >> square() method defaults to be sequential. >> >> Some benchmark results, run on my 1-6-2 server: >> >> >> Benchmark (n) Mode Cnt Score >> Error Units >> BigIntegerParallelMultiply.multiply100ss4 51.707 >> ± 11.194 ms/op >> BigIntegerParallelMultiply.multiply 1000ss4988.302 >> ± 235.977 ms/op >> BigIntegerParallelMultiply.multiply 1ss4 24662.063 >> ± 1123.329 ms/op >> BigIntegerParallelMultiply.parallelMultiply100ss4 49.337 >> ± 26.611 ms/op >> BigIntegerParallelMultiply.parallelMultiply 1000ss4527.560 >> ± 268.903 ms/op >> BigIntegerParallelMultiply.parallelMultiply 1ss4 9076.551 >> ± 1899.444 ms/op >> >> >> We can see that for larger calculations (fib 100m), the execution is 2.7x >> faster in parallel. For medium size (fib 10m) it is 1.873x faster. And for >> small (fib 1m) it is roughly the same. Considering that the fibonacci >> algorithm that we used was in itself sequential, and that the last 3 >> calculations would dominate, 2.7x faster should probably be considered quite >> good on a 1-6-2 machine. > > kabutz has updated the pull request incrementally with one additional commit > since the last revision: > > Changed depth type to byte to save 8 bytes on each RecursiveSquare instance "parallel multiple" -> "parallel multiply" "embarrassingly parallel when employing recursive" -> "embarrassingly non-parallel when employing recursive" (?) Even though it is technically bound by number of threads in the common pool (or whichever pool is executing the parallelMultiply()), I think that "bounded by the number of runtime processors" is close enough :-) - PR: https://git.openjdk.java.net/jdk/pull/6409
Re: RFR: 8278587: StringTokenizer(String, String, boolean) documentation bug [v2]
On Thu, 16 Dec 2021 18:41:32 GMT, Naoto Sato wrote: >> This is a doc fix to `StringTokenizer`, where the original spec does not >> account for the delimiter's length in the case of a supplementary character. >> Corresponding CSR has been drafted: >> https://bugs.openjdk.java.net/browse/JDK-8278814 > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Reflects CSR comments. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6836
Re: RFR: 8278587: StringTokenizer(String, String, boolean) documentation bug [v2]
On Thu, 16 Dec 2021 18:41:32 GMT, Naoto Sato wrote: >> This is a doc fix to `StringTokenizer`, where the original spec does not >> account for the delimiter's length in the case of a supplementary character. >> Corresponding CSR has been drafted: >> https://bugs.openjdk.java.net/browse/JDK-8278814 > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Reflects CSR comments. Marked as reviewed by darcy (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6836
RFR: 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java
The proposed fix is to address the performance degradation caused by the fix to JDK-8275721. Some amount of the degradation cannot be avoided as the lookup now falls back up to the bundles at Locale.ROOT. However, by lowering the fallback priority of `regionFormatFallback` than `COMPAT`'s lookup, it can avoid the excess bundle lookups for regions. I also changed the test case `TestZoneTextPrinterParser.java`, which currently iterates over 3 nested loops, i.e., all-locales x all-timezones x 8, which is absolutely unnecessary. Made it to sample some locales. In addition, I added a microbenchmark for the DateFormatSymbols.getZoneStrings() method. Here is the result: Before the fix to JDK-8275721: BenchmarkMode Cnt Score Error Units ZoneStrings.testZoneStringsss5 6.865 ± 0.696 s/op Before the proposed fix: BenchmarkMode Cnt Score Error Units ZoneStrings.testZoneStringsss5 15.741 ± 4.300 s/op After the proposed fix: BenchmarkMode Cnt Score Error Units ZoneStrings.testZoneStringsss5 9.756 ± 3.685 s/op - Commit messages: - Added a microbenchmark for zone strings - 8278434: timeouts in test java/time/test/java/time/format/TestZoneTextPrinterParser.java Changes: https://git.openjdk.java.net/jdk/pull/6790/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6790=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278434 Stats: 72 lines in 3 files changed: 59 ins; 7 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/6790.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6790/head:pull/6790 PR: https://git.openjdk.java.net/jdk/pull/6790
Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v6]
On Thu, 16 Dec 2021 19:39:59 GMT, kabutz wrote: > Terribly sorry to ask this, but where would I see the CSR? I don't have > access to the JIRA in the backend. You should be able to view it but not edit: https://bugs.openjdk.java.net/browse/JDK-8278886 (To get creation/update access rights you need to become an OpenJDK author.) If you have comments/edits the easier approach is to comment on this PR and I can update. - PR: https://git.openjdk.java.net/jdk/pull/6409
Re: RFR: 8278587: StringTokenizer(String, String, boolean) documentation bug [v2]
On Thu, 16 Dec 2021 18:41:32 GMT, Naoto Sato wrote: >> This is a doc fix to `StringTokenizer`, where the original spec does not >> account for the delimiter's length in the case of a supplementary character. >> Corresponding CSR has been drafted: >> https://bugs.openjdk.java.net/browse/JDK-8278814 > > Naoto Sato has updated the pull request incrementally with one additional > commit since the last revision: > > Reflects CSR comments. Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6836
Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v6]
On Thu, 16 Dec 2021 05:55:14 GMT, kabutz wrote: >> This is looking good. I will create the CSR and propose it. Since the >> holiday season is imminent it's likely no approval of the CSR will happen on >> until the new year. > >> This is looking good. I will create the CSR and propose it. Since the >> holiday season is imminent it's likely no approval of the CSR will happen on >> until the new year. > > Thank you so much Paul. > @kabutz @bplb CSR is created, can you please review? Terribly sorry to ask this, but where would I see the CSR? I don't have access to the JIRA in the backend. - PR: https://git.openjdk.java.net/jdk/pull/6409
Re: RFR: 8278587: StringTokenizer(String, String, boolean) documentation bug [v2]
> This is a doc fix to `StringTokenizer`, where the original spec does not > account for the delimiter's length in the case of a supplementary character. > Corresponding CSR has been drafted: > https://bugs.openjdk.java.net/browse/JDK-8278814 Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Reflects CSR comments. - Changes: - all: https://git.openjdk.java.net/jdk/pull/6836/files - new: https://git.openjdk.java.net/jdk/pull/6836/files/1fcb399d..45bb8396 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=6836=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=6836=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6836.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6836/head:pull/6836 PR: https://git.openjdk.java.net/jdk/pull/6836
Re: RFR: 8213905: reflection not working for type annotations applied to exception types in the inner class constructor
On Thu, 16 Dec 2021 17:44:04 GMT, Vicente Romero wrote: > Hi, > > Please review this change that is fixing a bug in reflection in particular in > `sun.reflect.annotation.TypeAnnotationParser::buildAnnotatedTypes` the > current code is assuming that for inner class constructors it is always > working on type annotations on parameters, but it is also invoked to extract > type annotations applied to exception types for example. > > TIA Hi Vicente. Please file a CSR for the behavioral change. - PR: https://git.openjdk.java.net/jdk/pull/6869
RFR: 8213905: reflection not working for type annotations applied to exception types in the inner class constructor
Hi, Please review this change that is fixing a bug in reflection in particular in `sun.reflect.annotation.TypeAnnotationParser::buildAnnotatedTypes` the current code is assuming that for inner class constructors it is always working on type annotations on parameters, but it is also invoked to extract type annotations applied to exception types for example. TIA - Commit messages: - 8213905: Reflection, TYPE_USE annotation on THROWS on inner class constructor, Java 9+ Changes: https://git.openjdk.java.net/jdk/pull/6869/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6869=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8213905 Stats: 16 lines in 2 files changed: 11 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6869.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6869/head:pull/6869 PR: https://git.openjdk.java.net/jdk/pull/6869
[jdk18] Integrated: 8278574: update --help-extra message to include default value of --finalization option
On Thu, 16 Dec 2021 06:33:24 GMT, Stuart Marks wrote: > A small modification to the Launcher's help text. This pull request has now been integrated. Changeset: be6b90d9 Author:Stuart Marks URL: https://git.openjdk.java.net/jdk18/commit/be6b90d90b54883ff17f9f5ac0f271de37df7e2a Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8278574: update --help-extra message to include default value of --finalization option Reviewed-by: sundar, alanb, lancea, mchung - PR: https://git.openjdk.java.net/jdk18/pull/34
Re: RFR: JDK-8277175 : Add a parallel multiply method to BigInteger [v6]
On Thu, 16 Dec 2021 05:55:14 GMT, kabutz wrote: >> This is looking good. I will create the CSR and propose it. Since the >> holiday season is imminent it's likely no approval of the CSR will happen on >> until the new year. > >> This is looking good. I will create the CSR and propose it. Since the >> holiday season is imminent it's likely no approval of the CSR will happen on >> until the new year. > > Thank you so much Paul. @kabutz @bplb CSR is created, can you please review? - PR: https://git.openjdk.java.net/jdk/pull/6409
Re: [jdk18] RFR: 8278574: update --help-extra message to include default value of --finalization option
On Thu, 16 Dec 2021 06:33:24 GMT, Stuart Marks wrote: > A small modification to the Launcher's help text. Marked as reviewed by mchung (Reviewer). - PR: https://git.openjdk.java.net/jdk18/pull/34
Re: [jdk18] RFR: 8278897: Alignment of heap segments is not enforced correctly
On Thu, 16 Dec 2021 12:31:01 GMT, Maurizio Cimadamore wrote: > This PR fixes an issue with alignment constraints not being enforced > correctly on on-heap segments dereference/copy operations. Alignment of > on-heap segments cannot be computed exactly, as alignment of elements in > arrays is, ultimately a VM implementation detail. Because of this, alignment > checks on heap segments can fail or pass depending on the platform being used. > > For more details about the problem and the solution please refer to: > https://mail.openjdk.java.net/pipermail/panama-dev/2021-November/015852.html Javadoc: http://cr.openjdk.java.net/~mcimadamore/8278897/v1/javadoc/jdk/incubator/foreign/package-summary.html Specdiff: http://cr.openjdk.java.net/~mcimadamore/8278897/v1/specdiff_out/overview-summary.html - PR: https://git.openjdk.java.net/jdk18/pull/37
[jdk18] RFR: 8278897: Alignment of heap segments is not enforced correctly
This PR fixes an issue with alignment constraints not being enforced correctly on on-heap segments dereference/copy operations. Alignment of on-heap segments cannot be computed exactly, as alignment of elements in arrays is, ultimately a VM implementation detail. Because of this, alignment checks on heap segments can fail or pass depending on the platform being used. For more details about the problem and the solution please refer to: https://mail.openjdk.java.net/pipermail/panama-dev/2021-November/015852.html - Commit messages: - Initial push Changes: https://git.openjdk.java.net/jdk18/pull/37/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18=37=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278897 Stats: 600 lines in 20 files changed: 566 ins; 0 del; 34 mod Patch: https://git.openjdk.java.net/jdk18/pull/37.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/37/head:pull/37 PR: https://git.openjdk.java.net/jdk18/pull/37
Re: [jdk18] RFR: 8278574: update --help-extra message to include default value of --finalization option
On Thu, 16 Dec 2021 06:33:24 GMT, Stuart Marks wrote: > A small modification to the Launcher's help text. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk18/pull/34
Integrated: 8278642: Refactor java.util.Formatter
On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad wrote: > A few refactorings to how `java.util.Formatter` sets up `FormatString`s, > aligning the implementation with changes explored by the TemplatedStrings JEP > and ever so slightly improving performance: > > - turn `Flags` into an `int` (fewer allocations in the complex case) > - remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> > `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the > complex cases since these varargs arrays were being allocated. Also improves > error messages since all bad flags will be listed in the exception message. > - make `FormatSpecifier` and `FixedString` static, reducing size of these > objects slightly. > > Baseline: > > Benchmark Mode Cnt > Score Error Units > StringFormat.complexFormat avgt 25 > 8977.043 ± 246.810 ns/op > StringFormat.complexFormat:·gc.alloc.rate.norm avgt 25 > 2144.170 ± 0.012B/op > StringFormat.stringFormat avgt 25 > 252.109 ± 2.732 ns/op > StringFormat.stringFormat:·gc.alloc.rate.norm avgt 25 > 256.019 ± 0.001B/op > StringFormat.stringIntFormatavgt 25 > 576.423 ± 4.596 ns/op > StringFormat.stringIntFormat:·gc.alloc.rate.normavgt 25 > 432.034 ± 0.002B/op > StringFormat.widthStringFormat avgt 25 > 999.835 ± 20.127 ns/op > StringFormat.widthStringFormat:·gc.alloc.rate.norm avgt 25 > 525.509 ± 14.742B/op > StringFormat.widthStringIntFormat avgt 25 > 1332.163 ± 30.901 ns/op > StringFormat.widthStringIntFormat:·gc.alloc.rate.norm avgt 25 > 720.715 ± 8.798B/op > > > Patch: > > Benchmark Mode Cnt > ScoreError Units > StringFormat.complexFormat avgt 25 > 8840.089 ± 51.222 ns/op > StringFormat.complexFormat:·gc.alloc.rate.norm avgt 25 > 1736.151 ± 0.009B/op > StringFormat.stringFormat avgt 25 > 247.310 ± 2.091 ns/op > StringFormat.stringFormat:·gc.alloc.rate.norm avgt 25 > 248.018 ± 0.001B/op > StringFormat.stringIntFormatavgt 25 > 565.487 ± 6.572 ns/op > StringFormat.stringIntFormat:·gc.alloc.rate.normavgt 25 > 408.032 ± 0.002B > StringFormat.widthStringFormat avgt 25 > 970.015 ± 32.915 ns/op > StringFormat.widthStringFormat:·gc.alloc.rate.norm avgt 25 > 449.991 ± 25.716B/op > StringFormat.widthStringIntFormat avgt 25 > 1284.572 ± 28.829 ns/op > StringFormat.widthStringIntFormat:·gc.alloc.rate.norm avgt 25 > 636.872 ± 7.331B/op This pull request has now been integrated. Changeset: aae56398 Author:Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/aae563981c89d922c51005626b39c31e377cadc5 Stats: 333 lines in 1 file changed: 0 ins; 39 del; 294 mod 8278642: Refactor java.util.Formatter Reviewed-by: rriggs, naoto - PR: https://git.openjdk.java.net/jdk/pull/6821
Re: RFR: 8278642: Refactor java.util.Formatter
On Tue, 14 Dec 2021 00:14:32 GMT, Claes Redestad wrote: > A few refactorings to how `java.util.Formatter` sets up `FormatString`s, > aligning the implementation with changes explored by the TemplatedStrings JEP > and ever so slightly improving performance: > > - turn `Flags` into an `int` (fewer allocations in the complex case) > - remove some superfluous varargs: `checkBadFlags(Flags.PARENTHESES, ...` -> > `checkBadFlags(Flags.Parentheses | ...` - again less allocations in the > complex cases since these varargs arrays were being allocated. Also improves > error messages since all bad flags will be listed in the exception message. > - make `FormatSpecifier` and `FixedString` static, reducing size of these > objects slightly. > > Baseline: > > Benchmark Mode Cnt > Score Error Units > StringFormat.complexFormat avgt 25 > 8977.043 ± 246.810 ns/op > StringFormat.complexFormat:·gc.alloc.rate.norm avgt 25 > 2144.170 ± 0.012B/op > StringFormat.stringFormat avgt 25 > 252.109 ± 2.732 ns/op > StringFormat.stringFormat:·gc.alloc.rate.norm avgt 25 > 256.019 ± 0.001B/op > StringFormat.stringIntFormatavgt 25 > 576.423 ± 4.596 ns/op > StringFormat.stringIntFormat:·gc.alloc.rate.normavgt 25 > 432.034 ± 0.002B/op > StringFormat.widthStringFormat avgt 25 > 999.835 ± 20.127 ns/op > StringFormat.widthStringFormat:·gc.alloc.rate.norm avgt 25 > 525.509 ± 14.742B/op > StringFormat.widthStringIntFormat avgt 25 > 1332.163 ± 30.901 ns/op > StringFormat.widthStringIntFormat:·gc.alloc.rate.norm avgt 25 > 720.715 ± 8.798B/op > > > Patch: > > Benchmark Mode Cnt > ScoreError Units > StringFormat.complexFormat avgt 25 > 8840.089 ± 51.222 ns/op > StringFormat.complexFormat:·gc.alloc.rate.norm avgt 25 > 1736.151 ± 0.009B/op > StringFormat.stringFormat avgt 25 > 247.310 ± 2.091 ns/op > StringFormat.stringFormat:·gc.alloc.rate.norm avgt 25 > 248.018 ± 0.001B/op > StringFormat.stringIntFormatavgt 25 > 565.487 ± 6.572 ns/op > StringFormat.stringIntFormat:·gc.alloc.rate.normavgt 25 > 408.032 ± 0.002B > StringFormat.widthStringFormat avgt 25 > 970.015 ± 32.915 ns/op > StringFormat.widthStringFormat:·gc.alloc.rate.norm avgt 25 > 449.991 ± 25.716B/op > StringFormat.widthStringIntFormat avgt 25 > 1284.572 ± 28.829 ns/op > StringFormat.widthStringIntFormat:·gc.alloc.rate.norm avgt 25 > 636.872 ± 7.331B/op Re-ran tier1+2 in our CI due to the mystery error in GHA testing. All passed. - PR: https://git.openjdk.java.net/jdk/pull/6821
Re: RFR: 8278831: Use table lookup for the last two bytes in Integer.getChars
On Wed, 15 Dec 2021 23:04:37 GMT, Claes Redestad wrote:
> During TemplatedStrings work Jim has noticed that we could probably profit
> from reusing the lookup tables also for the 1 or 2 leftmost bytes:
>
> // We know there are at most two digits left at this point.
> buf[--charPos] = DigitOnes[-i];
> if (i < -9) {
> buf[--charPos] = DigitTens[-i];
> }
>
> This avoids some arithmetic, and on average achieves a small speed-up since
> the lookup tables are likely cached are likely to be in cache. Small
> improvements on a few affected microbenchmarks, including the new
> Integers.toStringTiny, can be observed.
>
> Baseline:
>
> Benchmark (size) Mode Cnt Score Error Units
> Integers.toStringTiny 500 avgt 50 21.862 ± 0.211 us/op
>
>
> Patch:
>
> Benchmark (size) Mode Cnt Score Error Units
> Integers.toStringTiny 500 avgt 50 20.619 ± 0.330 us/op
Marked as reviewed by jlaskey (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6854
RFR: 8278831: Use table lookup for the last two bytes in Integer.getChars
During TemplatedStrings work Jim has noticed that we could probably profit from
reusing the lookup tables also for the 1 or 2 leftmost bytes:
// We know there are at most two digits left at this point.
buf[--charPos] = DigitOnes[-i];
if (i < -9) {
buf[--charPos] = DigitTens[-i];
}
This avoids some arithmetic, and on average achieves a small speed-up since the
lookup tables are likely cached are likely to be in cache. Small improvements
on a few affected microbenchmarks, including the new Integers.toStringTiny, can
be observed.
Baseline:
Benchmark (size) Mode Cnt Score Error Units
Integers.toStringTiny 500 avgt 50 21.862 ± 0.211 us/op
Patch:
Benchmark (size) Mode Cnt Score Error Units
Integers.toStringTiny 500 avgt 50 20.619 ± 0.330 us/op
-
Commit messages:
- 8278831: Use table lookup for the last two bytes in Integer.getChars
Changes: https://git.openjdk.java.net/jdk/pull/6854/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6854=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8278831
Stats: 42 lines in 4 files changed: 11 ins; 16 del; 15 mod
Patch: https://git.openjdk.java.net/jdk/pull/6854.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6854/head:pull/6854
PR: https://git.openjdk.java.net/jdk/pull/6854
Re: [jdk18] RFR: 8278574: update --help-extra message to include default value of --finalization option
On Thu, 16 Dec 2021 06:33:24 GMT, Stuart Marks wrote: > A small modification to the Launcher's help text. Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk18/pull/34
