On Mon, 26 Aug 2024 03:47:49 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix the issue
>> noted in https://bugs.openjdk.org/browse/JDK-8338445?
>>
>> The JDK internal class `jdk.internal.loader.URLClassPath` is used by
>> classloader implementations i
On Wed, 21 Aug 2024 00:25:03 GMT, Srinivas Vamsi Parasa
wrote:
> The goal of this PR is to implement an x86_64 intrinsic for
> java.lang.Math.tanh() using libm
>
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x
src/
Problem Description :
XSLT transformation creating unique namespace prefixes.
Analysis & Observation :
When upgrading from Java 8 to Java 17, the XSLT transformation is generating a
new namespace prefix for every XML element, even when the namespace value
matches that of the parent element. This
On Fri, 12 Jul 2024 06:29:34 GMT, Julian Waters wrote:
> snprintf has been available for all officially and unofficially supported
> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
> forever. snprintf is conforming to C99 since the start when compiling using
> gcc,
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start when compiling using
>>
On Mon, 26 Aug 2024 07:06:54 GMT, Alan Bateman wrote:
> Separately, I've often wondered how many plugins are putting file paths into
> the value by mistake, this has historically been an area of confusion.
You are right - the values that get used in a `Class-Path` entry keeps coming
up for dis
On Mon, 1 Jul 2024 21:48:44 GMT, Chen Liang wrote:
> `Method.invoke` and `Constructor.newInstance` wraps `Error` in
> `InvocationTargetException`, which is bug-prone for users. Worse, this is
> only ambiguously mentioned in the API specification.
>
> This patch proposes to explicitly mention t
On Mon, 26 Aug 2024 22:25:49 GMT, Shaojin Wen wrote:
>> This is a follow-up to PR #20273, which improves performance when the number
>> of parameters exceeds 20.
>>
>> When the number of parameters is large, the possibility of reuse will be
>> lower, so we can use the static concat method and
On Mon, 26 Aug 2024 22:25:49 GMT, Shaojin Wen wrote:
>> This is a follow-up to PR #20273, which improves performance when the number
>> of parameters exceeds 20.
>>
>> When the number of parameters is large, the possibility of reuse will be
>> lower, so we can use the static concat method and
On Thu, 22 Aug 2024 00:30:07 GMT, Jiangli Zhou wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also update build to link properly
>
> I compared the extracted changes in this PR with the related parts in
> h
On Mon, 26 Aug 2024 22:25:49 GMT, Shaojin Wen wrote:
>> This is a follow-up to PR #20273, which improves performance when the number
>> of parameters exceeds 20.
>>
>> When the number of parameters is large, the possibility of reuse will be
>> lower, so we can use the static concat method and
On Mon, 26 Aug 2024 22:29:03 GMT, Shaojin Wen wrote:
> At this time, caching is an additional overhead, and it takes longer to reach
> peak performance.
Can you elaborate on this line of thinking?
-
PR Comment: https://git.openjdk.org/jdk/pull/20675#issuecomment-2311280698
On Mon, 19 Aug 2024 07:19:30 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>>
On Wed, 21 Aug 2024 13:26:58 GMT, Maurizio Cimadamore
wrote:
> When working on startup improvements, I noticed that the method handle
> returned by `MemoryLayout::offsetHandle` can overflow if the client calls the
> handle with a base offset that is too big.
>
> In other similar situations, t
On Wed, 21 Aug 2024 13:24:15 GMT, Maurizio Cimadamore
wrote:
>> This PR fixes two minor issues in the `MemoryLayout` javadoc:
>> * the section describing dereference path talks about `P` and `P'` but then
>> only uses `P` in the code;
>> * the `ceilDiv` math on the `PathElement::sequenceElement
On Mon, 26 Aug 2024 22:25:49 GMT, Shaojin Wen wrote:
>> This is a follow-up to PR #20273, which improves performance when the number
>> of parameters exceeds 20.
>>
>> When the number of parameters is large, the possibility of reuse will be
>> lower, so we can use the static concat method and
> This is a follow-up to PR #20273, which improves performance when the number
> of parameters exceeds 20.
>
> When the number of parameters is large, the possibility of reuse will be
> lower, so we can use the static concat method and write the length and coder
> directly into the bytecode to
On Mon, 19 Aug 2024 07:19:30 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>>
On Mon, 26 Aug 2024 14:25:31 GMT, Per Minborg wrote:
>> It is true, that this is a compromise where we give up inline space,
>> code-cache space, and introduce added complexity against the prospect of
>> better small-size performance. Depending on the workload, this may or may
>> not pay off.
On Mon, 26 Aug 2024 20:51:35 GMT, Shaojin Wen wrote:
>> This is a follow-up to PR #20273, which improves performance when the number
>> of parameters exceeds 20.
>>
>> When the number of parameters is large, the possibility of reuse will be
>> lower, so we can use the static concat method and
On Mon, 26 Aug 2024 20:51:35 GMT, Shaojin Wen wrote:
>> This is a follow-up to PR #20273, which improves performance when the number
>> of parameters exceeds 20.
>>
>> When the number of parameters is large, the possibility of reuse will be
>> lower, so we can use the static concat method and
On Sun, 25 Aug 2024 13:10:41 GMT, Claes Redestad wrote:
> > If the number of parameters is greater than 2, the probability of reuse may
> > not be high. Using hard-coded constants can avoid the use of forceinline.
>
> I think this entirely depends on the application. Too low a threshold and
>
> This is a follow-up to PR #20273, which improves performance when the number
> of parameters exceeds 20.
>
> When the number of parameters is large, the possibility of reuse will be
> lower, so we can use the static concat method and write the length and coder
> directly into the bytecode to
On Sun, 25 Aug 2024 11:50:27 GMT, Shaojin Wen wrote:
> optimize the construction of MethodType and MethodTypeDesc to reduce memory
> allocate
This pull request has now been integrated.
Changeset: 5ecbecfb
Author:Shaojin Wen
Committer: Chen Liang
URL:
https://git.openjdk.org/jdk/co
On Sun, 25 Aug 2024 21:40:14 GMT, Shaojin Wen wrote:
>> optimize the construction of MethodType and MethodTypeDesc to reduce memory
>> allocate
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> use MethodTypeDescImpl.ofValida
On Sun, 25 Aug 2024 21:40:14 GMT, Shaojin Wen wrote:
>> optimize the construction of MethodType and MethodTypeDesc to reduce memory
>> allocate
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> use MethodTypeDescImpl.ofValida
On Sat, 24 Aug 2024 13:53:32 GMT, Chen Liang wrote:
> If Hotspot now parses these files incorrectly, it might be worth to just
> throw UnsupportedClassVersionError for oak class files?
I was informed in offline discussion that this is unlikely to be changed and
this change is unlikely to be ba
On Mon, 26 Aug 2024 03:47:49 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix the issue
>> noted in https://bugs.openjdk.org/browse/JDK-8338445?
>>
>> The JDK internal class `jdk.internal.loader.URLClassPath` is used by
>> classloader implementations i
On Fri, 23 Aug 2024 12:34:17 GMT, Claes Redestad wrote:
> This PR refactors SwitchBootstraps so that extra EnumDescs and classes are
> only passed into bootstraps when needed. Benchmarking shows that in many
> cases these are not needed, and avoiding passing them (via binding in the
> lists vi
On Sat, 24 Aug 2024 21:16:34 GMT, Claes Redestad wrote:
>> This PR refactors SwitchBootstraps so that extra EnumDescs and classes are
>> only passed into bootstraps when needed. Benchmarking shows that in many
>> cases these are not needed, and avoiding passing them (via binding in the
>> list
On Mon, 26 Aug 2024 12:24:30 GMT, Julian Waters wrote:
> If no objections are raised by tomorrow morning I'll proceed with integration
I've run this PR against latest mainline in our CI for tier1, tier2 and tier3
and there were no failures. So yes, I think you can go ahead with the
integration
On Mon, 26 Aug 2024 15:36:25 GMT, Jaikiran Pai wrote:
>> Is the if statement at line 470 redundant then? Presumably the code can
>> reach here.
>
> Hello Michael,
>> Is the if statement at line 470 redundant then?
>
> `Loader.getClassPath()` can return null (and it does for some implementations
On Wed, 21 Aug 2024 00:25:03 GMT, Srinivas Vamsi Parasa
wrote:
> The goal of this PR is to implement an x86_64 intrinsic for
> java.lang.Math.tanh() using libm
>
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x
This
On Mon, 26 Aug 2024 15:27:39 GMT, Daniel Fuchs wrote:
>> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 470:
>>
>>> 468: continue;
>>> 469: }
>>> 470: if (loaderClassPathURLs != null) {
>>
>> I'm missing something here. Why does th
On Mon, 26 Aug 2024 15:33:58 GMT, Michael McMahon wrote:
>> Because we would not reach here - since it's either assigned at line 447 or
>> we continue at line 457, 468, or exit throwing an uncaught exception?
>
> Is the if statement at line 470 redundant then? Presumably the code can reach
> he
On Mon, 26 Aug 2024 15:00:29 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java
>> line 86:
>>
>>> 84: var amo = attributeMapperOption;
>>> 85: for (var o : options) {
>>> 86: if (o instanceof StackMapsOption oo) {
>>
On Tue, 20 Aug 2024 10:24:25 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which suggests to deprecate the unused class
> `java.util.zip.ZipError` for removal.
>
> The class has been unsed by OpenJDK since the ZIP API was rewritten from
> native to Java in JDK 9.
>
> I opted to not expl
The goal of this PR is to implement an x86_64 intrinsic for
java.lang.Math.tanh() using libm
Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
-- | -- | -- | --
MathBench.tanhDouble | 70900 | 95618 | 1.35x
-
Commit messages:
- Fix bug in NaN path
- 8338694: x86_64 intrinsi
On Mon, 26 Aug 2024 15:17:18 GMT, Michael McMahon wrote:
>> Jaikiran Pai has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - revert to old code comment
>> - use "JAR file" consistently in test's code comments
>> - rename closeLoaderIgn
On Fri, 19 Jul 2024 15:36:10 GMT, Liam Miller-Cushon wrote:
>> This change fixes a zip64 bug in the launcher that is prevent it from
>> reading the manifest of jars where the 'relative offset of local header'
>> field in the central directory entry is >4GB. As described in APPNOTE.TXT
>> 4.5.3
On Mon, 26 Aug 2024 03:47:49 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix the issue
>> noted in https://bugs.openjdk.org/browse/JDK-8338445?
>>
>> The JDK internal class `jdk.internal.loader.URLClassPath` is used by
>> classloader implementations i
On Mon, 26 Aug 2024 14:54:59 GMT, Per Minborg wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Copyright
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java
> line 86:
>
>> 84:
On Mon, 26 Aug 2024 13:52:35 GMT, Claes Redestad wrote:
>> Noticed these on a few startup tests in code generating proxies. Desugaring
>> switch expressions reduce risk of bootstrap circularity from any future
>> changes to switch bootstrapping (which itself depends on the classfile API).
>> I
On Sat, 24 Aug 2024 21:16:34 GMT, Claes Redestad wrote:
>> This PR refactors SwitchBootstraps so that extra EnumDescs and classes are
>> only passed into bootstraps when needed. Benchmarking shows that in many
>> cases these are not needed, and avoiding passing them (via binding in the
>> list
On Mon, 26 Aug 2024 13:39:44 GMT, Claes Redestad wrote:
> Noticed these on a few startup tests in code generating proxies. Desugaring
> switch expressions reduce risk of bootstrap circularity from any future
> changes to switch bootstrapping (which itself depends on the classfile API).
> It's
On Mon, 26 Aug 2024 13:52:35 GMT, Claes Redestad wrote:
>> Noticed these on a few startup tests in code generating proxies. Desugaring
>> switch expressions reduce risk of bootstrap circularity from any future
>> changes to switch bootstrapping (which itself depends on the classfile API).
>> I
On Mon, 26 Aug 2024 13:52:35 GMT, Claes Redestad wrote:
>> Noticed these on a few startup tests in code generating proxies. Desugaring
>> switch expressions reduce risk of bootstrap circularity from any future
>> changes to switch bootstrapping (which itself depends on the classfile API).
>> I
On Mon, 26 Aug 2024 13:29:40 GMT, Per Minborg wrote:
>> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
>> line 200:
>>
>>> 198: switch ((int) length) {
>>> 199: case 0 : checkReadOnly(false); checkValidState();
>>> break; // Explicit
On Mon, 26 Aug 2024 14:00:22 GMT, Claes Redestad wrote:
>> #14404 caused some startup regressions, where the main cause of startup
>> increase in that change was due the use of - and the not very optimized
>> state of - runtime bootstrapped switches. This was remedied by a series of
>> optimiz
On Sat, 24 Aug 2024 10:51:53 GMT, Thomas Stuefe wrote:
> I don't think the costs for two address comparisons matter, not with the
> comparatively few deallocations that happen (few hundreds or few thousand).
> If deallocate is hot, we are using metaspace wrong.
MethodData does a lot of dealloc
> #14404 caused some startup regressions, where the main cause of startup
> increase in that change was due the use of - and the not very optimized state
> of - runtime bootstrapped switches. This was remedied by a series of
> optimizations to the switch bootstrap methods and finally a desugarin
On Mon, 26 Aug 2024 13:57:46 GMT, Claes Redestad wrote:
>> #14404 caused some startup regressions, where the main cause of startup
>> increase in that change was due the use of - and the not very optimized
>> state of - runtime bootstrapped switches. This was remedied by a series of
>> optimiz
On Mon, 26 Aug 2024 13:49:25 GMT, Claes Redestad wrote:
>> Noticed these on a few startup tests in code generating proxies. Desugaring
>> switch expressions reduce risk of bootstrap circularity from any future
>> changes to switch bootstrapping (which itself depends on the classfile API).
>> I
> Noticed these on a few startup tests in code generating proxies. Desugaring
> switch expressions reduce risk of bootstrap circularity from any future
> changes to switch bootstrapping (which itself depends on the classfile API).
> It's also a tiny improvement to startup performance.
Claes Red
On Mon, 26 Aug 2024 13:30:18 GMT, Claes Redestad wrote:
> #14404 caused some startup regressions, where the main cause of startup
> increase in that change was due the use of - and the not very optimized state
> of - runtime bootstrapped switches. This was remedied by a series of
> optimizatio
On Mon, 26 Aug 2024 13:39:44 GMT, Claes Redestad wrote:
> Noticed these on a few startup tests in code generating proxies. Desugaring
> switch expressions reduce risk of bootstrap circularity from any future
> changes to switch bootstrapping (which itself depends on the classfile API).
> It's
Noticed these on a few startup tests in code generating proxies. Desugaring
switch expressions reduce risk of bootstrap circularity from any future changes
to switch bootstrapping (which itself depends on the classfile API). It's also
a tiny improvement to startup performance.
-
Co
On Sun, 25 Aug 2024 02:08:38 GMT, Chen Liang wrote:
>> Claes Redestad has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Update src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
>>
>>Co-authored-by: ExE Boss <388
On Mon, 26 Aug 2024 12:07:02 GMT, Per Minborg wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add a comment about the old switch type
>
> Here is what it looks like for Windows x64:
>
> ` method call with calling `checkReadOnly()` instead (as the
>> bounds of the segment itself do not need to be checked).
>>
>> Also, smaller seg
On Mon, 26 Aug 2024 12:07:02 GMT, Per Minborg wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add a comment about the old switch type
>
> Here is what it looks like for Windows x64:
>
> ` method call with calling `checkReadOnly()` instead (as the
>> bounds of the segment itself do not need to be checked).
>>
>> Also, smaller seg
> The performance of the `MemorySegment::fil` can be improved by replacing the
> `checkAccess()` method call with calling `checkReadOnly()` instead (as the
> bounds of the segment itself do not need to be checked).
>
> Also, smaller segments can be handled directly by Java code rather than
> tr
> The performance of the `MemorySegment::fil` can be improved by replacing the
> `checkAccess()` method call with calling `checkReadOnly()` instead (as the
> bounds of the segment itself do not need to be checked).
>
> Also, smaller segments can be handled directly by Java code rather than
> tr
> The performance of the `MemorySegment::fil` can be improved by replacing the
> `checkAccess()` method call with calling `checkReadOnly()` instead (as the
> bounds of the segment itself do not need to be checked).
>
> Also, smaller segments can be handled directly by Java code rather than
> tr
The performance of the `MemorySegment::fil` can be improved by replacing the
`checkAccess()` method call with calling `checkReadOnly()` instead (as the
bounds of the segment itself do not need to be checked).
Also, smaller segments can be handled directly by Java code rather than
transitioning
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start when compiling using
>>
On Sun, 25 Aug 2024 22:03:56 GMT, Markus Karg wrote:
> Could it be the case that you posted twice the exact same performance
> numbers? I do not see any actual difference in your numbers.
He did, then updated the numbers and posted this comment:
> The same data is used in the diff section abov
On Mon, 26 Aug 2024 02:07:39 GMT, David Holmes wrote:
> but it still impacts every single Java run just to save some time/resources
> for the handful of builders of statically linked VMs.
Seriously? I challenge you do prove there is any effect at all. :-/
Also, there is not a "handful" of buil
On Sun, 25 Aug 2024 14:57:22 GMT, Alan Bateman wrote:
> That is true for now but there 30-50 other places that will need attention
> once this effort is further along. Everywhere that deals with user editable
> configuration (conf tree) will change, as will everywhere that reads JDK
> internal
On Sun, 25 Aug 2024 21:40:14 GMT, Shaojin Wen wrote:
>> optimize the construction of MethodType and MethodTypeDesc to reduce memory
>> allocate
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> use MethodTypeDescImpl.ofValida
On Mon, 26 Aug 2024 03:47:49 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix the issue
>> noted in https://bugs.openjdk.org/browse/JDK-8338445?
>>
>> The JDK internal class `jdk.internal.loader.URLClassPath` is used by
>> classloader implementations i
On Mon, 13 May 2024 10:42:26 GMT, Maurizio Cimadamore
wrote:
> This PR implements [JEP 472](https://openjdk.org/jeps/472), by restricting
> the use of JNI in the following ways:
>
> * `System::load` and `System::loadLibrary` are now restricted methods
> * `Runtime::load` and `Runtime::loadLibr
On Mon, 26 Aug 2024 03:47:49 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to fix the issue
>> noted in https://bugs.openjdk.org/browse/JDK-8338445?
>>
>> The JDK internal class `jdk.internal.loader.URLClassPath` is used by
>> classloader implementations i
77 matches
Mail list logo
