On Mon, 3 Jun 2024 14:38:03 GMT, Alexey Semenyuk wrote:
>> I am yet to see anything that actually explains the cause of the `dlerror`
>> crash here ???
>
> @dholmes-ora there is no fix for the cause of the `dlerror` crash in this PR.
> The PR fixes jpackage tests to rerun a launcher if it
On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov wrote:
> JVM routinely installs loader constraints for unloaded signature classes when
> method resolution takes place. MethodHandle resolution took a different route
> and eagerly resolves signature classes instead (see
>
On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov wrote:
>> JVM routinely installs loader constraints for unloaded signature classes
>> when method resolution takes place. MethodHandle resolution took a different
>> route and eagerly resolves signature classes instead (see
>>
On Tue, 4 Jun 2024 01:29:15 GMT, Alexey Semenyuk wrote:
> > Is there plan to add support for WiX 5?
>
> This patch supports WiX5 as well. There is not much difference between WiX4
> and WiX5 from jpackage perspective. I'll update the description
I assume WiX5 will just work if installed
Run the below benchmark test ,it show the average time of new DecimalFormat()
increase 18% when compare to jdk 11.
the result with jdk 11:
Benchmark Mode CntScore Error Units
JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op
the result
> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic
> instructions. But when run with JDK 11, there is no such problem. The reason
> is the removed biased locking.
> The DecimalFormat uses StringBuffer everywhere, and
On Mon, 3 Jun 2024 04:25:38 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test-only change which uncomments an
> additional test that was commented out in
> `test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java`?
>
> As noted in
On Mon, 3 Jun 2024 04:25:38 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test-only change which uncomments an
> additional test that was commented out in
> `test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java`?
>
> As noted in
On Mon, 3 Jun 2024 06:13:35 GMT, lingjun-cg wrote:
>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic
>> instructions. But when run with JDK 11, there is no such problem. The
>> reason is the removed biased locking.
On Tue, 4 Jun 2024 01:24:15 GMT, Alexander Matveev wrote:
> Is there plan to add support for WiX 5?
This patch supports WiX5 as well. There is not much difference between WiX4 and
WiX5 from jpackage perspective. I'll update the description
-
PR Comment:
On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla wrote:
>> I added `@since` tags for methods/constructors that do not match the
>> `@since` of the enclosing class.
>>
>> The `write` method already existed in `PrintStream` in earlier versions and
>> instances of it could always call this
On Mon, 3 Jun 2024 06:13:35 GMT, lingjun-cg wrote:
>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic
>> instructions. But when run with JDK 11, there is no such problem. The
>> reason is the removed biased locking.
Please review this PR which handles incorrect CompactNumberFormat integer only
parsing when there is no suffix.
See the following snippet,
var fmt = NumberFormat.getCompactNumberInstance(Locale.US,
NumberFormat.Style.SHORT)
fmt.setParseIntegerOnly(true)
fmt.parse("5K") // returns 5000
On Mon, 3 Jun 2024 21:53:06 GMT, Alexander Matveev wrote:
> This added functionality is not used. It is completely unclear from PR and/or
> issue description why we need this and how it will be used in the future?
It was supposed to be used in [WiX4
On Mon, 3 Jun 2024 20:29:47 GMT, Alexey Semenyuk wrote:
> 8333452: Make logging in jdk.jpackage.internal.OverridableResource class
> configurable
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/19532
On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov wrote:
>> JVM routinely installs loader constraints for unloaded signature classes
>> when method resolution takes place. MethodHandle resolution took a different
>> route and eagerly resolves signature classes instead (see
>>
On Fri, 17 May 2024 18:04:02 GMT, Justin Lu wrote:
> Please review this PR which is a trivial update to the IANA sub tag registry
> to version 2024-05-16. Locale tests pass as expected after update.
>
> Associated announcement ->
>
On Mon, 3 Jun 2024 20:29:47 GMT, Alexey Semenyuk wrote:
> 8333452: Make logging in jdk.jpackage.internal.OverridableResource class
> configurable
OverridableResource uses Log.verbose, which will log if -verbose is specified.
What do you mean by "OverridableResource class unconditionally
On Mon, 3 Jun 2024 17:26:52 GMT, Nizar Benalla wrote:
> Can I please get a review for this small change? The motivation is that javac
> does not recognize `package.html` files.
>
> The conversion was simple, I used a script to rename the files, append "*" on
> the left and remove some HTML
Hi folks,
It feels a bit strange that you can't pass an `InstantSource` to
`Instant.now(...)`, but you _can_ pass a `Clock` (which of course has a
"useless" `ZoneId` when creating an `Instant`). Therefore, I'd like to
propose one of the following API changes:
1) adding
On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov wrote:
>> JVM routinely installs loader constraints for unloaded signature classes
>> when method resolution takes place. MethodHandle resolution took a different
>> route and eagerly resolves signature classes instead (see
>>
On Mon, 3 Jun 2024 20:29:47 GMT, Alexey Semenyuk wrote:
> 8333452: Make logging in jdk.jpackage.internal.OverridableResource class
> configurable
@sashamatveev, please review
-
PR Comment: https://git.openjdk.org/jdk/pull/19532#issuecomment-2146097131
8333452: Make logging in jdk.jpackage.internal.OverridableResource class
configurable
-
Commit messages:
- 8333452: Make logging in jdk.jpackage.internal.OverridableResource class
configurable
Changes: https://git.openjdk.org/jdk/pull/19532/files
Webrev:
> JVM routinely installs loader constraints for unloaded signature classes when
> method resolution takes place. MethodHandle resolution took a different route
> and eagerly resolves signature classes instead (see
> `java.lang.invoke.MemberName$Factory::resolve` and
>
On Tue, 21 May 2024 20:14:41 GMT, Jorn Vernee wrote:
>> Class loading triggered by `Class.forName()` call is at the core of
>> `isTypeVisible`. (The rest is fast path checks.) It's what makes
>> `isTypeVisible` query idempotent.
>>
>> I can definitely name it differently (e.g,
On Mon, 3 Jun 2024 15:40:10 GMT, Severin Gehwolf wrote:
> Does that proposal sound good?
That table is useful, I think it's right. No change to default behavior. If
someone configures with --enable-runtime-image then they get a JDK run-time
image that supports jlink (with some limitations)
On Mon, 3 Jun 2024 17:07:28 GMT, Aleksey Shipilev wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
On Mon, 3 Jun 2024 16:47:20 GMT, jengebr wrote:
> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
> cloning of Object[0] instances. This cloning is intended to prevent callers
> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
> to size
Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
cloning of Object[0] instances. This cloning is intended to prevent callers
from changing array contents, but many `CopyOnWriteArrayList`s are allocated to
size zero, or are otherwise maintained empty, so cloning is
On Mon, 3 Jun 2024 16:47:20 GMT, jengebr wrote:
> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
> cloning of Object[0] instances. This cloning is intended to prevent callers
> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
> to size
Can I please get a review for this small change? The motivation is that javac
does not recognize `package.html` files.
The conversion was simple, I used a script to rename the files, append "*" on
the left and remove some HTML tags like and . I did the conversion
in place, renaming them in
On Tue, 28 May 2024 17:25:34 GMT, Sean Gwizdak wrote:
> Improve the speed of Method.hashCode by caching the hashcode on first use.
> I've seen an application where Method.hashCode is a hot path, and this is a
> fairly simple speedup. The memory overhead is low.
>
> This addresses issue
>
> Improve the speed of Method.hashCode by caching the hashcode on first use.
> I've seen an application where Method.hashCode is a hot path, and this is a
> fairly simple speedup. The memory overhead is low.
>
> This addresses issue
>
On Mon, 13 May 2024 20:14:38 GMT, Nizar Benalla wrote:
>> Please review this PR that aims to add all the remaining needed `@since`
>> tags in `java.base`, and group them into a single fix.
>> This is related to #18934 and my work around the `@since` checker feature.
>> Explicit `@since` tags
On Wed, 29 May 2024 19:51:36 GMT, Naoto Sato wrote:
> There is an initialization code in `Console` class that searches for the
> Console implementations. Refactoring the init code not to use lambda/stream
> would reduce the (initial) number of loaded classes by about 100 for
> java.base
On Thu, 30 May 2024 19:48:25 GMT, Naoto Sato wrote:
>> There is an initialization code in `Console` class that searches for the
>> Console implementations. Refactoring the init code not to use lambda/stream
>> would reduce the (initial) number of loaded classes by about 100 for
>> java.base
On Mon, 3 Jun 2024 12:55:54 GMT, Alan Bateman wrote:
> So I think we may have the wrong default. Yes, they are separate configure
> and jlink options but I'm wondering if it would be more sensible to
> opt-in(not opt-out) to keep the packaged modules when configured with
>
Hi,
What's the status of Project Brisbane? According to [1], the Project
was approved two month ago on April 4th, but until now I can't find it
listed on openjdk.org nor can I find a corresponding mailing list?
Best regards,
Volker
[1]
> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
> classfile API for reflection proxy-generation. Actual implementation of
> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
> regressions. `ProxyGenerator.TEMPLATE` class model is statically
On Mon, 3 Jun 2024 08:37:50 GMT, David Holmes wrote:
>> Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app
>> launcher instead of raw Executor. This makes MainClassTest test run app
>> launchers with retries. This change addresses the primary issue.
>>
>> Fix
On Mon, 27 May 2024 12:20:20 GMT, Chen Liang wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> performance improvements
>
> src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java line 76:
>
>> 74:
>> 75:
> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
> classfile API for reflection proxy-generation. Actual implementation of
> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
> regressions. `ProxyGenerator.TEMPLATE` class model is statically
On Tue, 21 May 2024 13:49:18 GMT, jengebr wrote:
> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
> Class[0] instances. This cloning is intended to prevent callers from
> changing array contents, but many Methods have zero exceptions or zero
> parameters, and
On Sun, 2 Jun 2024 17:41:55 GMT, Alan Bateman wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 110 commits:
>>
>> - Merge branch 'master' into jdk-8311302-jmodless-link
>> - Fix new line in
On Mon, 3 Jun 2024 11:16:49 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1345:
>>
>>> 1343: int b = base, p = top, cap;
>>> 1344: if (p - b > 0 && a != null && (cap = a.length) > 0) {
>>> 1345: for (int m
On Mon, 3 Jun 2024 11:37:34 GMT, Claes Redestad wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> ProxyGenBench simplification
>
> test/micro/org/openjdk/bench/java/lang/reflect/Proxy/ProxyGenBench.java line
> 23:
>
> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
> classfile API for reflection proxy-generation. Actual implementation of
> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
> regressions. `ProxyGenerator.TEMPLATE` class model is statically
> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
> classfile API for reflection proxy-generation. Actual implementation of
> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
> regressions. `ProxyGenerator.TEMPLATE` class model is statically
On Mon, 3 Jun 2024 11:09:31 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>>
On Sun, 2 Jun 2024 14:33:45 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reconcile changes
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1345:
>
>> 1343:
> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
> classfile API for reflection proxy-generation. Actual implementation of
> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
> regressions. `ProxyGenerator.TEMPLATE` class model is statically
On Mon, 3 Jun 2024 10:30:03 GMT, Claes Redestad wrote:
>> Adam Sotona has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> added ProxyGenBench JMH micro benchmark
>
> test/micro/org/openjdk/bench/java/lang/reflect/Proxy/ProxyGenBench.java
On Mon, 3 Jun 2024 05:46:30 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which updates the API specification
>> of `java.util.zip.InflaterInputStream.skip()` method to match its current
>> implementation?
>>
>> `InflaterInputStream.skip()`, just like
On Mon, 3 Jun 2024 04:25:38 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test-only change which uncomments an
> additional test that was commented out in
> `test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java`?
>
> As noted in
On Mon, 3 Jun 2024 10:11:34 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>>
On Sun, 2 Jun 2024 17:41:55 GMT, Alan Bateman wrote:
> I've been looking through the changes. One thing that I'm wondering about is
> whether --generate-runtime-link-image should disable the keeping of packaged
> modules (set JLINK_KEEP_PACKAGED_MODULES to false). It seems surprising to
> use
> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
> classfile API for reflection proxy-generation. Actual implementation of
> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
> regressions. `ProxyGenerator.TEMPLATE` class model is statically
On Wed, 29 May 2024 07:17:38 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>>
On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie wrote:
> The original way of building static libraries in the JDK was to use the
> configure argument --enable-static-build, which set the value of the make
> variable STATIC_BUILD. (Note that this is not the same as the source code
>
On Wed, 22 May 2024 22:38:16 GMT, Oussama Louati wrote:
>> test/jdk/java/lang/invoke/CallStaticInitOrder.java line 54:
>>
>>> 52:
>>> 53: static int Init1Tick;
>>> 54: public static class Init1 {
>>
>> Is there a reason to change all the classes and methods to public?
>
> the test
On Fri, 3 May 2024 16:05:30 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that enforces
>>
On Fri, 31 May 2024 14:05:07 GMT, Alexey Semenyuk wrote:
> Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app
> launcher instead of raw Executor. This makes MainClassTest test run app
> launchers with retries. This change addresses the primary issue.
>
> Fix
On Fri, 31 May 2024 18:39:33 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic
> instructions. But when run with JDK 11, there is no such problem. The reason
> is the removed biased locking.
> The DecimalFormat uses StringBuffer everywhere, and
64 matches
Mail list logo
