On Mon, 19 May 2025 03:49:20 GMT, Jan Lahoda wrote:
>> A consider class like this:
>>
>>
>> public class TwoMains {
>> private static void main(String... args) {}
>> static void main() {
>> System.out.println("Should be called, but is not.");
>> }
>> }
>>
>>
>> The `Method
On Fri, 11 Apr 2025 10:52:03 GMT, Aleksey Shipilev wrote:
>> As far as I can tell, intrinsic selection only applies when the call target
>> is
>> exactly the intrinsically attributed method. (Possibly after optimizations
>> that lead to a call to that specific method.) And that's obviously neces
On Fri, 9 May 2025 07:35:41 GMT, Xiaohong Gong wrote:
> JDK-8318650 introduced hotspot intrinsification of subword gather load APIs
> for X86 platforms [1]. However, the current implementation is not optimal for
> AArch64 SVE platform, which natively supports vector instructions for subword
>
> A consider class like this:
>
>
> public class TwoMains {
> private static void main(String... args) {}
> static void main() {
> System.out.println("Should be called, but is not.");
> }
> }
>
>
> The `MethodFinder` will do lookup for the `main(String[])` method, and it
>
> `isArray` and null return is now redundant when `componentType` is changed to
> an explicit field.
Chen Liang has updated the pull request incrementally with one additional
commit since the last revision:
For parity with MT.descriptorString
-
Changes:
- all: https://git.open
> This PR implements nth root computation for BigIntegers using Newton method.
fabioromano1 has updated the pull request incrementally with one additional
commit since the last revision:
Do first refinement loop only if shift == 0
-
Changes:
- all: https://git.openjdk.org/jdk/p
The test was originally written with product builds in mind; it didn't consider
the slowness of debug builds, thus causing tests to fail.
Also there was a bug in testWeakAgainstClassValue: the test need to flush the
backing map in the class to have the weak value removed. It is fixed in this
pa
On Sun, 18 May 2025 18:18:04 GMT, Joe Darcy wrote:
> Did you consider calling getComponentType(), which already returns the field?
I don't think we want an extra indirection here - The logic here is quite
simple. Counterargument could be that `MethodType::descriptorString` calls
`toMethodDescr
On Sun, 18 May 2025 12:11:21 GMT, Alan Bateman wrote:
>> Kim Barrett has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move jdk.internal.nio.Cleaner to sun.nio
>
> src/java.base/share/classes/jdk/internal/nio/Cleaner.java line 26:
>
>> 24
On Sun, 18 May 2025 11:35:55 GMT, Kim Barrett wrote:
> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use
> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
>
> This change is algorithmica
Hi Markus,
I think you can submit a draft PR - while some people here like Alan Bateman
use draft PRs to indicate "not ready for any review" and discussions are not
forwarded to the mailing lists, they are still very useful for looking at the
change set.
Note that we are a few short weeks from
This sounds like a very interesting proposal. If we can split up the
constructor, we might be able to merge the two separate yes replacement
(constructor) and no replacement (NoRepl) implementations into one down the
road.
I saw the PR https://github.com/openjdk/jdk/pull/25290, and from the dif
It's perhaps easier to just add an annotation @ForceInlining.
regards,
Rémi
> From: "wenshao"
> To: "core-libs-dev"
> Sent: Sunday, May 18, 2025 5:51:15 PM
> Subject: C2 inlining failed because the String constructor is too large
> Through JVM Option +PrintInlining, we found that String has
On Sat, 17 May 2025 02:15:42 GMT, Chen Liang wrote:
> `isArray` and null return is now redundant when `componentType` is changed to
> an explicit field.
src/java.base/share/classes/java/lang/Class.java line 3985:
> 3983: @Override
> 3984: public Class componentType() {
> 3985:
Through JVM Option +PrintInlining, we found that String has a constructor
codeSize of 852, which is too large. This caused failed to inline.
The following is the output information of PrintInlining:
```
@ 9 java.lang.String:: (12 bytes) inline (hot)
!m @ 1 java.nio.charset.Charset::defaultCharset
Sorry, the posting below was cross-posted by accident.
-Markus
Am 18.05.2025 um 17:09 schrieb Markus KARG:
Roger,
thank you for your comments.
Following your advice I have splitted the larger work of JDK-8356679
into sub tasks.
I would like to start with a first PR implementing the *found
Roger,
thank you for your comments.
Following your advice I have splitted the larger work of JDK-8356679
into sub tasks.
I would like to start with a first PR implementing the *foundational*
work, i. e. optimizing Writer::append for efficiency (JDK-8357183). For
convenience, attached below
On Sun, 18 May 2025 11:35:55 GMT, Kim Barrett wrote:
> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use
This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
use java.lang.ref.Cleaner.
This change is algorithmically similar
20 matches
Mail list logo
