Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

2024-09-01 Thread Julian Waters
On Mon, 2 Sep 2024 04:09:19 GMT, David Holmes wrote: > > This does make me wonder: What if the new method for checking if the VM was > > statically linked was inlined? Then the problem comes back yet again as the > > object files need to be recompiled once more. This is possible if Link Time >

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

2024-09-01 Thread David Holmes
On Sun, 1 Sep 2024 16:30:33 GMT, Julian Waters wrote: > This does make me wonder: What if the new method for checking if the VM was > statically linked was inlined? Then the problem comes back yet again as the > object files need to be recompiled once more. This is possible if Link Time > Opti

Re: RFR: 8328877: [JNI] The JNI Specification needs to address the limitations of integer UTF-8 String lengths [v2]

2024-09-01 Thread David Holmes
On Fri, 30 Aug 2024 20:45:11 GMT, Chris Plummer wrote: >> David Holmes has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Exclude test on 32-bit > > Overall it looks good to me, although I don't have experience adding a new > JNI API (the

Re: RFR: 8339358: Optimize TypeKind#from

2024-09-01 Thread Shaojin Wen
On Thu, 29 Aug 2024 05:34:37 GMT, Shaojin Wen wrote: > TypeKind.from(Class) is a frequently called method, which provides a > specialized method to improve performance. > > The following Compiler log shows that the call stack level is reduced and two > reference accesses (descriptorString() ->

Re: RFR: 8339358: Optimize TypeKind#from

2024-09-01 Thread Shaojin Wen
On Fri, 30 Aug 2024 00:19:35 GMT, ExE Boss wrote: >> TypeKind.from(Class) is a frequently called method, which provides a >> specialized method to improve performance. >> >> The following Compiler log shows that the call stack level is reduced and >> two reference accesses (descriptorString()

Re: RFR: 8339358: Optimize TypeKind#from

2024-09-01 Thread Claes Redestad
On Thu, 29 Aug 2024 05:34:37 GMT, Shaojin Wen wrote: > TypeKind.from(Class) is a frequently called method, which provides a > specialized method to improve performance. > > The following Compiler log shows that the call stack level is reduced and two > reference accesses (descriptorString() ->

Re: RFR: 8339358: Optimize TypeKind#from

2024-09-01 Thread Claes Redestad
On Fri, 30 Aug 2024 01:21:14 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/java/lang/classfile/TypeKind.java line 176: >> >>> 174: if (cl == double.class ) return DoubleType; >>> 175: if (cl == void.class ) return VoidType; >>> 176: else ret

Re: RFR: 8339358: Optimize TypeKind#from

2024-09-01 Thread ExE Boss
On Thu, 29 Aug 2024 05:34:37 GMT, Shaojin Wen wrote: > TypeKind.from(Class) is a frequently called method, which provides a > specialized method to improve performance. > > The following Compiler log shows that the call stack level is reduced and two > reference accesses (descriptorString() ->

RFR: 8339358: Optimize TypeKind#from

2024-09-01 Thread Shaojin Wen
TypeKind.from(Class) is a frequently called method, which provides a specialized method to improve performance. The following Compiler log shows that the call stack level is reduced and two reference accesses (descriptorString() -> String.value) are reduced, which can reduce the performance deg

Re: RFR: 8339214: Remove misleading CodeBuilder.loadConstant(Opcode, ConstantDesc) [v2]

2024-09-01 Thread Abdelhak Zaaim
On Thu, 29 Aug 2024 21:46:52 GMT, Chen Liang wrote: >> `CodeBuilder::loadConstant(Opcode, ConstantDesc)` is error-prone and >> confusing. Users should almost always use `loadConstant(ConstantDesc)` for >> optimized instructions, or use specific factories `iconst_0` etc. or >> `bipush` with arg

Re: RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

2024-09-01 Thread Julian Waters
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

Re: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v4]

2024-09-01 Thread fabioromano1
> This implementation of MutableBigInteger.leftShift(int) optimizes the current > version, avoiding unnecessary copy of the MutableBigInteger's value content > and performing the primitive shifting only in the original portion of the > value array rather than in the value yet extended with trail

Re: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v3]

2024-09-01 Thread Raffaello Giulietti
On Sat, 31 Aug 2024 15:05:58 GMT, fabioromano1 wrote: >> This implementation of MutableBigInteger.leftShift(int) optimizes the >> current version, avoiding unnecessary copy of the MutableBigInteger's value >> content and performing the primitive shifting only in the original portion >> of the