Re: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries

On Wed, 2 Jun 2021 20:13:34 GMT, Maurizio Cimadamore wrote: >> This patch overhauls the library loading mechanism used by the Foreign >> Linker API. We realized that, while handy, the *default* lookup abstraction >> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. >>

Re: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v7]

On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore wrote: >> This patch overhauls the library loading mechanism used by the Foreign >> Linker API. We realized that, while handy, the *default* lookup abstraction >> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. >>

Re: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries

On Tue, 12 Oct 2021 15:04:02 GMT, Maurizio Cimadamore wrote: > Is libc.a loadable on AIX (e.g. with System.loadLibrary) ? I tried to load `libc.a` and `libc` this way but neither of them works on AIX. e.g. public class StdLibTest { private static CLinker clinker =

Re: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries

On Fri, 8 Oct 2021 21:29:19 GMT, Maurizio Cimadamore wrote: >> Hi @mcimadamore, >> >> As you mentioned at >> https://github.com/openjdk/jdk/pull/4316#issuecomment-853238872, the system >> lookup is supported by the underlying `NativeLibraries` which also works on >> OpenJDK16 to support

Re: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v7]

On Thu, 3 Jun 2021 20:49:44 GMT, Maurizio Cimadamore wrote: >> This patch overhauls the library loading mechanism used by the Foreign >> Linker API. We realized that, while handy, the *default* lookup abstraction >> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms. >>

RE: Incorrect assumption on the class name in compile(InputSource input, String name) at XSLTC.java

String baseName = Util.baseName(systemId); if ((baseName != null) && (baseName.length() > 0)) { <-- setClassName(baseName); } which means it should check whether the returned base name from Util.baseName(systemId) is empty befor

Re: Incorrect assumption on the class name in compile(InputSource input, String name) at XSLTC.java

t; in which case Util.baseName(systemId) returns null and setClassName(null) ended up with "die/verwandlung/" in generating the bytecode). So I expect someone in OpenJDK to take a look into this issue to see what really happened to the code there in such case. Thanks. Thanks and Best Regards Cheng Jin

Re: Incorrect assumption on the class name in compile(InputSource input, String name) at XSLTC.java

t; in which case Util.baseName(systemId) returns null and setClassName(null) ended up with "die/verwandlung/" in generating the bytecode). So I expect someone in OpenJDK to take a look into this issue to see what really happened to the code there in such case. Thanks. Thanks and Best Regards Cheng Jin

Incorrect assumption on the class name in compile(InputSource input, String name) at XSLTC.java

gth() > 0)) { <-- setClassName(baseName); } which means it should check whether the returned base name from Util.baseName(systemId) is empty before setting the class name; otherwise, it should use the default class name ("GregorSamsa"). Let me know if any other concern on this fix. Thanks and Best Regards Cheng Jin

Request for backport the OpenJDK fix in XSLTC.java to JDK11 & JDK17

p; !clsName.isEmpty()) { setClassName(clsName); } } With this fix at https://git.openjdk.java.net/jdk/pull/6620, would you please backport it to JDK11 & JDK17 given the code there is at the same place? Thanks in advance. Thanks and Best Regards Cheng Jin

Please help backport the fix with the XSLT compiler in JDK18 to JDK11 & JDK17

has been fixed in JDK18 via https://bugs.openjdk.java.net/browse/JDK-8276657. Could you help backport the fix to JDK11 and JDK17 give both of them share the same issue in code? Many thanks. Best Regards Cheng Jin

RE: When to initialize the method's class for MethodHandles.Lookup.findStatic()?

Test_2 was still verified in the test. So it is impossible to verify Test_2 if it is not initialized, which only means Test_2 is initialized during the lookup.findstatic rather than mh.invoke(). Best Regards Cheng - Original Message - > From: "Cheng Jin" > To: "core-libs-

RE: When to initialize the method's class for MethodHandles.Lookup.findStatic()?

>> reveals whether Test_2 has been initialized during the lookup. How >> can you tell? >> >> Finally, the method handle invocation in Test_1 will throw, as you >> don't pass any argument to a handle that expects one. >> >> Can you perhaps add more details

RE: When to initialize the method's class for MethodHandles.Lookup.findStatic()?

for MethodHandles.Lookup.findStatic()? Cheng, initialization is the last thing that happens because it's where user provided code gets executed. This has always been this way, as long as I can remember. See the JVMS for the gory details. Greetings Raffaello On 2022-03-18 01:21, Cheng Jin wrote: > Hi Da

Incorrect return value for Java_jdk_internal_loader_NativeLibraries_load() in java.base/share/native/libjava/NativeLibraries.c

m was spotted since JDK17) Best Regards Cheng Jin

When to initialize the method's class for MethodHandles.Lookup.findStatic()?

ed behaviour at this point and why OpenJDK doesn't comply with the document to delay the initialization of the method's class to mh.invoke(). Best Regards Cheng Jin