On Sun, 25 Aug 2024 15:14:15 GMT, Alan Bateman wrote:
> For the bug report then it would be interesting to know if there is a plugin
> in the eco system that is creating the bad values or whether it's just a
> one-off.
I ran a test against the corpus. Of the 900K odd artifacts, only 2 jar fil
On Sun, 25 Aug 2024 15:08:27 GMT, Alan Bateman 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 closeLoaderIgnore
> 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 in the JDK (for example by the
> `java.net.URLClassLoader` an
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 Wed, 21 Aug 2024 22:14:40 GMT, Magnus Ihse Bursie wrote:
>> As a preparation for Hermetic Java, we need to have a way to look up during
>> runtime if we are using a statically linked library or not.
>>
>> This change will be the first step needed towards compiling the object files
>> only o
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 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:29:17 GMT, ExE Boss wrote:
>> In this case, there are too many locations under the java.lang package to
>> change, and a new PR may be more appropriate.
>
> Well, `Class::descriptorString()` is referenced from the
> `ReferenceClassDescImpl` creation code in `ConstantUtil
> 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.ofValidated
-
Changes:
- all: https://git.openjdk.org/jdk/
On Sun, 25 Aug 2024 20:13:11 GMT, Chen Liang wrote:
> @wenshao Can you change all `MethodTypeDesc.of` and the
> `CONSTRUCTOR_METHOD_TYPE` static final fields in inlined strategy to be
> optimized too?
CONSTRUCTOR_METHOD_TYPE The current strategy is optimization:
MethodType CONSTRUCTOR_METHOD
On Sun, 25 Aug 2024 21:07:16 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/lang/StringConcatHelper.java line 787:
>>
>>> 785: }
>>> 786:
>>> 787: static String concat(String prefix, String value, String suffix) {
>>
>> `Class::descriptorString()` can probably also make u
On Sun, 25 Aug 2024 16:55:23 GMT, ExE Boss wrote:
>> Optimize ClassDesc related string concatenation, which will reduce object
>> allocation during startup.
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 787:
>
>> 785: }
>> 786:
>> 787: static String concat(Stri
On Sun, 25 Aug 2024 11:50:27 GMT, Shaojin Wen wrote:
> optimize the construction of MethodType and MethodTypeDesc to reduce memory
> allocate
@wenshao Can you change all `MethodTypeDesc.of` and the
`CONSTRUCTOR_METHOD_TYPE` static final fields in inlined strategy to be
optimized too?
---
On Sat, 24 Aug 2024 10:49:56 GMT, Eirik Bjørsnøs wrote:
> Please review this refactoring PR which moves the `ZipEntry.flags` field to
> `ZipOutputStream.XEntry`.
>
> Moving this field will save four bytes from the `ZipEntry` object size and
> also saves an unneccessary read in `ZipFile.getZipE
On Sun, 25 Aug 2024 11:50:27 GMT, Shaojin Wen wrote:
> optimize the construction of MethodType and MethodTypeDesc to reduce memory
> allocate
Marked as reviewed by redestad (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/20704#pullrequestreview-2259349847
On Sun, 25 Aug 2024 13:36:34 GMT, Shaojin Wen wrote:
> Optimize ClassDesc related string concatenation, which will reduce object
> allocation during startup.
src/java.base/share/classes/java/lang/StringConcatHelper.java line 787:
> 785: }
> 786:
> 787: static String concat(String pref
On Sat, 24 Aug 2024 10:49:56 GMT, Eirik Bjørsnøs wrote:
> Please review this refactoring PR which moves the `ZipEntry.flags` field to
> `ZipOutputStream.XEntry`.
>
> Moving this field will save four bytes from the `ZipEntry` object size and
> also saves an unneccessary read in `ZipFile.getZipE
On Fri, 23 Aug 2024 10:45: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 in the
On Sun, 25 Aug 2024 12:12:42 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 14:29:16 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 Fri, 23 Aug 2024 10:04:42 GMT, Magnus Ihse Bursie wrote:
> But, if you look at the actual functions that are affected, you can see that
> it is just a handful of calls that are all done at startup time.
That is true for now but there 30-50 other places that will need attention once
this ef
> 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
Optimize ClassDesc related string concatenation, which will reduce object
allocation during startup.
-
Commit messages:
- Optimize the string concatenation related to ClassDesc during startup
Changes: https://git.openjdk.org/jdk/pull/20705/files
Webrev: https://webrevs.openjdk.or
On Sun, 25 Aug 2024 13:22:04 GMT, Claes Redestad wrote:
>> If initCoder is UTF16, the coder method does not need to be generated. This
>> is an optimization and may be a separate PR. Of course, if you agree, I can
>> also put it here.
>
> Right, if `initCoder` is always UTF16 (`-XX:-CompactStri
On Sat, 24 Aug 2024 17:22:28 GMT, Chen Liang wrote:
> I think linking to the CSR would be fine, but there is no prerequisite for
> API specs to link to CSRs. Need @jddarcy to double check here. I was
> emulating `Thread.stop`:
>
> https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7c
On Sun, 25 Aug 2024 13:03:23 GMT, Shaojin Wen wrote:
>> Something to consider (for a follow up) is to not add the initial coder as
>> an argument but test that in the outer method: No point calling the `coder`
>> method if we already know that we're UTF-16.
>
> If initCoder is UTF16, the coder
On Sun, 25 Aug 2024 12:54:08 GMT, Shaojin Wen 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 many
applicat
On Sun, 25 Aug 2024 12:44:02 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line
>> 1200:
>>
>>> 1198: /**
>>> 1199: * Construct the MethodType of the coder method, if there are
>>> no parameters it may be UTF16, return null
On Sun, 25 Aug 2024 12:35:00 GMT, Claes Redestad wrote:
>> optimize the construction of MethodType and MethodTypeDesc to reduce memory
>> allocate
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line
> 1200:
>
>> 1198: /**
>> 1199: * Construct the Met
optimize the construction of MethodType and MethodTypeDesc to reduce memory
allocate
-
Commit messages:
- Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
- Optimize the construction of MethodType and MethodTypeDesc to reduce memory
allocate
Changes: h
On Sun, 25 Aug 2024 11:50:27 GMT, Shaojin Wen wrote:
> optimize the construction of MethodType and MethodTypeDesc to reduce memory
> allocate
Marked as reviewed by redestad (Reviewer).
src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1200:
> 1198: /**
> 1199:
On Sun, 25 Aug 2024 12:12:42 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 Sat, 27 Jul 2024 13:45:11 GMT, Shaojin Wen wrote:
> Similar to PR #20321, this improves performance by providing a method that
> passes in a StringBuilder to avoid unnecessary object allocation.
Since I am not responsible for the date time area, I would prefer @naotoj who's
more familiar to
On Sun, 25 Aug 2024 12:13:34 GMT, Shaojin Wen wrote:
> > * Can we try to optimize the default generation shape further before we
> > reach for this sort of specialization?
>
> I am also thinking about this, such as the optimization of Integer/Long type
> parameters. Is this what you are talkin
On Sun, 25 Aug 2024 11:25:11 GMT, Claes Redestad wrote:
> * Can we try to optimize the default generation shape further before we reach
> for this sort of specialization?
I am also thinking about this, such as the optimization of Integer/Long type
parameters. Is this what you are talking about
> 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 Thu, 22 Aug 2024 11:50:02 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 write
On Thu, 22 Aug 2024 11:50:02 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 write
38 matches
Mail list logo
