On Thu, 19 Sep 2024 07:40:43 GMT, Matthias Baesken wrote:
> Windows Server 2025 will be releases in a few months.
> The OS detection code of the JVM/JDK should recognize the new Windows server
> 2025 version.
> (currently Windows server 2022 is printed , that is wrong)
>
> The build numbers of
On Thu, 19 Sep 2024 07:40:43 GMT, Matthias Baesken wrote:
> Windows Server 2025 will be releases in a few months.
> The OS detection code of the JVM/JDK should recognize the new Windows server
> 2025 version.
> (currently Windows server 2022 is printed , that is wrong)
>
> The build numbers of
On Mon, 23 Sep 2024 05:11:34 GMT, Jaikiran Pai wrote:
> Can I please get a review of this trivial change which removes dead code from
> the `RequiresSetenv()` function?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8340596 this appears to be a
> left-over from the changes in https://bugs
On Sat, 21 Sep 2024 06:31:16 GMT, Alan Bateman wrote:
>> Calvin Cheung has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> trailing whitespace
>
> src/java.base/share/classes/jdk/internal/module/ModuleReferences.java line
> 105:
>
>> 103:
On Tue, 3 Sep 2024 17:32:43 GMT, Naoto Sato wrote:
> I don't think using SharedSecret just for performance improvement and code
> size reduction is the right way, as the class is the last resort as the
> header says:
>
> ```
> *
> * Usage of these APIs often means bad encapsulation designs,
> By removing the redundant code logic in
> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
> reduced and the performance can be improved.
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the
> By removing the redundant code logic in
> DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be
> reduced and the performance can be improved.
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
suggestion from @j
Can I please get a review of this trivial change which removes dead code from
the `RequiresSetenv()` function?
As noted in https://bugs.openjdk.org/browse/JDK-8340596 this appears to be a
left-over from the changes in https://bugs.openjdk.org/browse/JDK-8244224.
No new tests have been added and
On Mon, 23 Sep 2024 04:47:52 GMT, Jaikiran Pai wrote:
>> src/java.base/share/native/libjli/java.c line 1405:
>>
>>> 1403: * when launching java. It may be null, which implies the "-splash:"
>>> option wasn't used.
>>> 1404: * The jar_path is the value that was provided to the "-jar" option
>
On Mon, 23 Sep 2024 04:53:15 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to remove the
>> (internal) `SelectVersion()` function from the java launcher and also update
>> the code comments in the launcher to match the current implementation?
>>
>> As note
On Mon, 23 Sep 2024 04:41:00 GMT, David Holmes wrote:
>> Jaikiran Pai has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - move the code comment to a function comment
>> - clarify who sets the _JAVA_VERSION_SET environment variable
>
> src
> Can I please get a review of this change which proposes to remove the
> (internal) `SelectVersion()` function from the java launcher and also update
> the code comments in the launcher to match the current implementation?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the
> `Sel
On Sun, 22 Sep 2024 12:48:12 GMT, Jaikiran Pai wrote:
> Hello Matthias, please give me a day or two to run this against our internal
> CI to make sure there are no unexpected issues.
tier1, tier2, tier3 testing in our CI has completed successfully, so this looks
OK.
-
PR Comment:
On Mon, 23 Sep 2024 04:33:50 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to remove the
>> (internal) `SelectVersion()` function from the java launcher and also update
>> the code comments in the launcher to match the current implementation?
>>
>> As note
> Can I please get a review of this change which proposes to remove the
> (internal) `SelectVersion()` function from the java launcher and also update
> the code comments in the launcher to match the current implementation?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8340114, the
> `Sel
On Sun, 22 Sep 2024 15:00:04 GMT, Alan Bateman wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> treat -version: -jre-restrict-search and -jre-no-restrict-search like any
>> other unknown option
>
> src/java.base/sh
On Mon, 16 Sep 2024 17:50:52 GMT, Henry Jen wrote:
> This PR split out large array/set construction into separate factory methods
> to avoid oversized method trying to construct several of those.
>
> In order to do that, we will need to generate those help methods on demand in
> the class buil
On Thu, 19 Sep 2024 07:40:43 GMT, Matthias Baesken wrote:
> Windows Server 2025 will be releases in a few months.
> The OS detection code of the JVM/JDK should recognize the new Windows server
> 2025 version.
> (currently Windows server 2022 is printed , that is wrong)
>
> The build numbers of
Optimize checkAssignableTo to avoid clone when stackSize is 0, and use clone
instead of Array.copyOf to avoid compression and then expansion
-
Commit messages:
- suggestion from @liach
- optimize checkAssignableTo
Changes: https://git.openjdk.org/jdk/pull/21121/files
Webrev: htt
On Sun, 22 Sep 2024 14:08:38 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
>> line 1102:
>>
>>> 1100: target.localsSize = localsSize;
>>> 1101: if (stackSize > 0) {
>>> 1102: target.s
On Sun, 22 Sep 2024 14:14:11 GMT, Shaojin Wen wrote:
>> stack.length may be larger than stackSize. In this case, the length of the
>> array copied by clone will be longer than Arrays.copyOf. However, I have no
>> evidence that Arrays.copyOf is faster than clone.
>
> I found through debugging th
On Sun, 22 Sep 2024 13:37:38 GMT, Chen Liang wrote:
>> Optimize checkAssignableTo to avoid clone when stackSize is 0, and use clone
>> instead of Array.copyOf to avoid compression and then expansion
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
> line 1102:
On Sun, 22 Sep 2024 13:20:01 GMT, Shaojin Wen wrote:
> Optimize checkAssignableTo to avoid clone when stackSize is 0, and use clone
> instead of Array.copyOf to avoid compression and then expansion
src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
line 1102:
> 110
On Sun, Sep 22, 2024 at 2:03 PM Olexandr Rotan
wrote:
> Hello everyone! I am writing here today to invite everyone to participate
> in the discussion regarding the Range APi proposal I have made into JDK.
>
A few comments...
Guava has addressed this same problem; their approach worth reviewing:
On Fri, 20 Sep 2024 08:48:50 GMT, Maurizio Cimadamore
wrote:
> Just be clarify: is it your expectation that, in order for this issue to be
> fixed, we should fix the javadoc of all caller sensitive methods, addressing
> issues that have nothing to do with restricted-ness?
No, just the new res
Hello!
Thanks for your comments, they are valuable to me. I indeed intended to
make Range immutable, if you noticed, in potential methods I listed
extendTo and shrinkTo, which is kind of modified with-ers. But, it's indeed
better to convert range to class and expose some methods to create bounded
a
On 22/09/2024 17:45, Rafael Winterhalter wrote:
That is only true for Class::getResource which resolves resources
relative to the loaded class's class file location. Java agents
typically use ClassLoader::getResource(AsStream) as the loaded class
is not available in the general case of transfor
On Sun, Sep 22, 2024 at 6:46 PM Rafael Winterhalter
wrote:
Sorry, still not sure I understand the scenario..
That is only true for Class::getResource which resolves resources relative
> to the loaded class's class file location.
>
Class:getResource simply adds the package name prefix and calls
On Mon, 16 Sep 2024 11:42:46 GMT, Lance Andersen wrote:
>> I'm curious why the combined header length validation is being placed so
>> late. In general I would assume failing fast is better?
>>
>> Also, since the combined header length clause applies to "any directory
>> record", it also appli
In Byte Buddy, class files are typically looked up from a Java agent or a
build tool plugin. The underlying abstraction is a ClassFileLocator. In a
build tool, the locator is typically based on jar files or folders. Here,
the locator can determine that a jar or folder is multi-release by a
possible
That is only true for Class::getResource which resolves resources relative
to the loaded class's class file location. Java agents typically use
ClassLoader::getResource(AsStream) as the loaded class is not available in
the general case of transforming, and not retransforming, a class. For
example,
On 22/09/2024 16:42, Eirik Bjørsnøs wrote:
:
Alan,
JarFile.getVersionedEntry no longer searches the full historical
version range, but only tries the specific versions actually present
in the JAR file. So this probably isn't as bad as it sounds, assuming
most multi-release JARs only have e
On Sun, 22 Sep 2024 02:03:02 GMT, Chen Liang wrote:
> We should declare `count` before `ensureCapacitiyInternal`. Same for append
> boolean.
Declaring count before ensureCapacityInternal will cause performance regression
under x64. It took a lot of time to find this, but the underlying reason
On Sun, 22 Sep 2024 02:01:36 GMT, Chen Liang wrote:
>> Shaojin Wen 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 23 additional
>> commits sinc
> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into
> primitive arrays by combining values into larger stores.
>
> This PR rewrites the code of appendNull and append(boolean) methods so that
> these two methods can be optimized by C2.
Shaojin Wen has updated the pul
On Sat, Sep 21, 2024 at 11:15 PM Rafael Winterhalter
wrote:
> Hello,
> It is a quite common need for Java agents to resolve class files for Java
> classes by their name. Normally, this is done by requesting a resource from
> the class loader. So if a class:
>
> pkg.SampleClass
>
> is requested, t
On Sun, Sep 22, 2024 at 12:14 PM Alan Bateman
wrote:
> On 21/09/2024 22:14, Rafael Winterhalter wrote:
> > Hello,
> > It is a quite common need for Java agents to resolve class files for
> > Java classes by their name. Normally, this is done by requesting a
> > resource from the class loader.
>
>
On Mon, 16 Sep 2024 17:50:52 GMT, Henry Jen wrote:
> …nge while creating a jlink image
It would be helpful for potential reviewers if the PR description included a
brief summary on the changes to the code generated, otherwise it's a lot to
wade through to understand the changes.
-
On Fri, 6 Sep 2024 13:16:34 GMT, Kevin Rushforth wrote:
>> Looks good. I'll review the CSR when its ready.
>
>> Looks good. I'll review the CSR when its ready.
>
> Thanks.
>
>> The changes to make jdk.jsobject an upgradeable module looks right.
>
> Thanks for checking. My testing primarily foc
On Tue, 17 Sep 2024 11:27:39 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to remove the
>> (internal) `SelectVersion()` function from the java launcher and also update
>> the code comments in the launcher to match the current implementation?
>>
>> As note
On Tue, 17 Sep 2024 11:27:39 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to remove the
>> (internal) `SelectVersion()` function from the java launcher and also update
>> the code comments in the launcher to match the current implementation?
>>
>> As note
On Thu, 19 Sep 2024 07:40:43 GMT, Matthias Baesken wrote:
> Windows Server 2025 will be releases in a few months.
> The OS detection code of the JVM/JDK should recognize the new Windows server
> 2025 version.
> (currently Windows server 2022 is printed , that is wrong)
>
> The build numbers of
On Tue, 17 Sep 2024 16:13:55 GMT, Quan Anh Mai wrote:
> Hi,
>
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just
> the revert of the backout.
>
> Regarding the related issues:
>
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and
> [JDK-8309531](ht
On 21/09/2024 22:14, Rafael Winterhalter wrote:
Hello,
It is a quite common need for Java agents to resolve class files for
Java classes by their name. Normally, this is done by requesting a
resource from the class loader.
I agree that the scalability issue with MR JARs deserves attention. JE
44 matches
Mail list logo
