Re: RFR: 8350209: Preserve adapters in AOT cache [v4]

2025-04-18 Thread Vladimir Kozlov
> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class > information in AOT cache which helps Java startup performance. > > We should also preserve adapters (i2c, c2i) to further improve performance of > class linking where adapters are generated. > > Short running Java applic

Re: RFR: 8354996: Reduce dynamic code generation for a single downcall [v2]

2025-04-18 Thread Chen Liang
On Fri, 18 Apr 2025 18:15:09 GMT, Jorn Vernee wrote: >> So just `Linker.nativeLinker().downcallHandle(MemorySegment.ofArray(new >> byte[0]), signature)` suffices? > > Yes, that would work, but I was thinking just > `Linker.nativeLinker().downcallHandle(signature)` Yep, simplified this, the sta

Re: RFR: 8354996: Reduce dynamic code generation for a single downcall [v2]

2025-04-18 Thread Chen Liang
> Perf numbers for simple main: > Linking of `Class::forName0` down from ~152 to ~83 > > For calling little color management system > https://bugs.openjdk.org/browse/JDK-8313344: > JNI: ~45 > baseline panama: ~164 > patch: ~103 > > Also see #24705. Chen Liang has updated the pull request increm

Re: RFR: 8354996: Reduce dynamic code generation for a single downcall

2025-04-18 Thread Jorn Vernee
On Fri, 18 Apr 2025 17:56:53 GMT, Chen Liang wrote: >> make/jdk/src/classes/build/tools/classlist/HelloClasslist.java line 190: >> >>> 188: JAVA_BOOLEAN, ADDRESS, ADDRESS); >>> 189: Optional symbol = >>> lookup.find("Java_java_lang_Class_forName0"); >>> 190: var

Re: RFR: 8350209: Preserve adapters in AOT cache [v3]

2025-04-18 Thread Vladimir Kozlov
> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class > information in AOT cache which helps Java startup performance. > > We should also preserve adapters (i2c, c2i) to further improve performance of > class linking where adapters are generated. > > Short running Java applic

Re: RFR: 8354996: Reduce dynamic code generation for a single downcall

2025-04-18 Thread Chen Liang
On Fri, 18 Apr 2025 17:49:35 GMT, Jorn Vernee wrote: >> Perf numbers for simple main: >> Linking of `Class::forName0` down from ~152 to ~83 >> >> For calling little color management system >> https://bugs.openjdk.org/browse/JDK-8313344: >> JNI: ~45 >> baseline panama: ~164 >> patch: ~103 >> >>

Re: RFR: 8354996: Reduce dynamic code generation for a single downcall

2025-04-18 Thread Jorn Vernee
On Thu, 17 Apr 2025 19:44:07 GMT, Chen Liang wrote: > Perf numbers for simple main: > Linking of `Class::forName0` down from ~152 to ~83 > > For calling little color management system > https://bugs.openjdk.org/browse/JDK-8313344: > JNI: ~45 > baseline panama: ~164 > patch: ~103 > > Also see #

Re: RFR: 8354902: Change to Visual Studio 17.13.2 for building on Windows at Oracle

2025-04-18 Thread Erik Joelsson
On Thu, 17 Apr 2025 01:17:50 GMT, Mikael Vidstedt wrote: > Oracle is updating the version of Visual Studio for building the JDK on > Windows to Visual Studio 2022 17.13.2. > > Testing: tier1-5 Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/2

RFR: 8354919: Move HotSpot .editorconfig into the global .editorconfig

2025-04-18 Thread Julian Waters
The src/hotspot directory should ideally only be used for HotSpot source files, and we should avoid polluting it with an .editorconfig. A cleaner solution exists since we can just specify the desired code formatting for HotSpot as an override in the root .editorconfig - Commit mess

Re: RFR: 8350209: Preserve adapters in AOT cache

2025-04-18 Thread Vladimir Kozlov
On Fri, 18 Apr 2025 06:01:43 GMT, Ashutosh Mehra wrote: > @vnkozlov I forgot to remove `AOTCodeSection` from `code/aotCodeCache.hpp` > when I refactored the APIs. This struct is no longer used. Can you please > remove it. Done. - PR Comment: https://git.openjdk.org/jdk/pull/24740

Re: RFR: 8350209: Preserve adapters in AOT cache [v2]

2025-04-18 Thread Vladimir Kozlov
> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class > information in AOT cache which helps Java startup performance. > > We should also preserve adapters (i2c, c2i) to further improve performance of > class linking where adapters are generated. > > Short running Java applic