Re: fast way to infer caller
Good morning! On 4/7/22 23:59, Kasper Nielsen wrote: Hi Michael, I don't really have an opinion on how you obtain a logger. But one particular use-case I've had was that I would like to perform some access checks based on the module of the caller. Something similar to how Panama checks for native access: Reflection.ensureNativeAccess(Reflection.getCallerClass()); Hmh, but wouldn't it be sufficient to perform these checks at initialization time? On 4/7/22 21:01, Ralph Goers wrote: > In Log4j’s case there are two places that accessing the stack comes into play: > 1. Obtaining a Logger . > 2. Logging an event and including the caller’s location information. > > To be honest, what sucks for Logging frameworks is that we really want > access to the location information at compile time such that the overhead > to include it would be zero. I’ve never understood why Java doesn’t include it. That I totally agree! Having the exact line number in the log statement would be a huge win. But to be honest, Reflection::getCallerClass wouldn't help either. I agree that such an inlined statement would be a huge win. But to also put this into relation: From my opinion, logging frameworks should be most performant in the cases where they are *not* logging. Or in those cases where you would log a lot even in production environment - like for financial calculations - the exact line number isn't that relevant any more. But that's just my opinion. -Michael
RFR: 8284336: CDS SignedJar.java test fails due to archived Reference object
During `java -Xshare:dump`, `ClassLoaders.bootLoader().resourceCache` is usually null. However, if a signed class is loaded, `resourceCache` will point to a `java.lang.ref.SoftReference`. Although rare (we have never seen this during our testing), it's possible for `resourceCache.discovered` to directly or indirectly point to another `Reference` which may contain an object that cannot be archived. The fix is simple: reset the `resourceCache` field of all three archived ClassLoader objects (boot/platform/app). I cannot reproduce the problem and I am unable to write a deterministic test case. However, the bug reporter has tested my preliminary patch and is no longer able to reproduce the failure. Please see the bug report [JDK-8284336](https://bugs.openjdk.java.net/browse/JDK-8284336) for detailed analysis and traces. - Commit messages: - 8284336: CDS SignedJar.java test fails due to archived Reference object Changes: https://git.openjdk.java.net/jdk/pull/8151/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8151=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284336 Stats: 28 lines in 5 files changed: 25 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8151/head:pull/8151 PR: https://git.openjdk.java.net/jdk/pull/8151
Re: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12]
On Fri, 8 Apr 2022 01:05:33 GMT, Srinivas Vamsi Parasa wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in >> java.lang.Integer and java.lang.Long classes using x86 intrinsics. This >> change shows 3x improvement for Integer methods and upto 25% improvement for >> Long. This change also implements the DivMod optimization which fuses >> division and modulus operations if needed. The DivMod optimization shows 3x >> improvement for Integer and ~65% improvement for Long. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one > additional commit since the last revision: > > uncomment zero in integer div, mod test Personally, I think the optimisation for `div < 0` should be handled by the mid-end optimiser, which will not only give us the advantages of dead code elimination, but also global code motion. I would suggest the backend only doing `xorl rdx, rdx; divl $div$$Register` and the optimisation for `div < 0` will be implemented as a part of JDK-8282365. What do you think? Thanks. - PR: https://git.openjdk.java.net/jdk/pull/7572
Re: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12]
On Fri, 8 Apr 2022 01:05:33 GMT, Srinivas Vamsi Parasa wrote: >> Optimizes the divideUnsigned() and remainderUnsigned() methods in >> java.lang.Integer and java.lang.Long classes using x86 intrinsics. This >> change shows 3x improvement for Integer methods and upto 25% improvement for >> Long. This change also implements the DivMod optimization which fuses >> division and modulus operations if needed. The DivMod optimization shows 3x >> improvement for Integer and ~65% improvement for Long. > > Srinivas Vamsi Parasa has updated the pull request incrementally with one > additional commit since the last revision: > > uncomment zero in integer div, mod test Good. I forgot before to ask about how you handle devision by 0 and now you added check for it. Let me run testing before approval. - PR: https://git.openjdk.java.net/jdk/pull/7572
Re: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v12]
> Optimizes the divideUnsigned() and remainderUnsigned() methods in > java.lang.Integer and java.lang.Long classes using x86 intrinsics. This > change shows 3x improvement for Integer methods and upto 25% improvement for > Long. This change also implements the DivMod optimization which fuses > division and modulus operations if needed. The DivMod optimization shows 3x > improvement for Integer and ~65% improvement for Long. Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: uncomment zero in integer div, mod test - Changes: - all: https://git.openjdk.java.net/jdk/pull/7572/files - new: https://git.openjdk.java.net/jdk/pull/7572/files/bfb6c02e..3e3fc977 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7572=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7572=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572 PR: https://git.openjdk.java.net/jdk/pull/7572
Re: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v4]
On Wed, 6 Apr 2022 00:45:37 GMT, Vladimir Kozlov wrote: >> Thanks for suggesting the enhancement. This enhancement will be implemented >> as a part of https://bugs.openjdk.java.net/browse/JDK-8282365 > > You do need `Ideal()` methods at least to check for dead code. Added the Ideal() methods for checking dead code. Pls see the new commit. - PR: https://git.openjdk.java.net/jdk/pull/7572
Re: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v8]
On Wed, 6 Apr 2022 00:46:01 GMT, Vladimir Kozlov wrote:
>> Srinivas Vamsi Parasa has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> add error msg for jtreg test
>
> I have few comments.
Hi Vladimir (@vnkozlov),
Incorporated all the suggestions you made in the previous review and pushed a
new commit.
Please let me know if anything else is needed.
Thanks,
Vamsi
> src/hotspot/cpu/x86/assembler_x86.cpp line 12375:
>
>> 12373: }
>> 12374: #endif
>> 12375:
>
> Please, place it near `idivq()` so you would not need `#ifdef`.
Made the change as per your suggestion.
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4568:
>
>> 4566: subl(rdx, divisor);
>> 4567: if (VM_Version::supports_bmi1()) andnl(rax, rdx, rax);
>> 4568: else {
>
> Please, follow our coding stile here and in following methods:
>
> if (VM_Version::supports_bmi1()) {
> andnl(rax, rdx, rax);
> } else {
Pls see the new commit which fixed the coding style.
> src/hotspot/cpu/x86/x86_64.ad line 8701:
>
>> 8699: %}
>> 8700:
>> 8701: instruct udivI_rReg(rax_RegI rax, no_rax_rdx_RegI div, rFlagsReg cr,
>> rdx_RegI rdx)
>
> I suggest to follow the pattern in other `div/mod` instructions: `(rax_RegI
> rax, rdx_RegI rdx, no_rax_rdx_RegI div, rFlagsReg cr)`
>
> Similar in following new instructions.
Pls see the new commit which fixed the pattern.
> test/hotspot/jtreg/compiler/intrinsics/TestIntegerDivMod.java line 55:
>
>> 53: dividends[i] = rng.nextInt();
>> 54: divisors[i] = rng.nextInt();
>> 55: }
>
> I don't trust RND to generate corner cases.
> Please, add cases here and in TestLongDivMod.java for MAX, MIN, 0.
You are right. Using an updated corner cases test revealed divide by zero crash
which was fixed. Please see the updated jtreg tests inspired by unsigned
divide/remainder tests in test/jdk/java/lang/Long/Unsigned.java and
test/jdk/java/lang/Integer/Unsigned.java.
-
PR: https://git.openjdk.java.net/jdk/pull/7572
Re: RFR: 8282221: x86 intrinsics for divideUnsigned and remainderUnsigned methods in java.lang.Integer and java.lang.Long [v11]
> Optimizes the divideUnsigned() and remainderUnsigned() methods in > java.lang.Integer and java.lang.Long classes using x86 intrinsics. This > change shows 3x improvement for Integer methods and upto 25% improvement for > Long. This change also implements the DivMod optimization which fuses > division and modulus operations if needed. The DivMod optimization shows 3x > improvement for Integer and ~65% improvement for Long. Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: Idead Ideal for udiv, umod nodes and update jtreg tests to use corner cases - Changes: - all: https://git.openjdk.java.net/jdk/pull/7572/files - new: https://git.openjdk.java.net/jdk/pull/7572/files/9949047c..bfb6c02e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7572=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7572=09-10 Stats: 701 lines in 7 files changed: 423 ins; 274 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7572.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7572/head:pull/7572 PR: https://git.openjdk.java.net/jdk/pull/7572
Re: [External] : Re: jpackage usage problems
Hi Hiran, Thank you for providing all the details! I can see two separate issues with jpackage: 1. jpackage reports NPE if it can't figure out the package name from the supplied application image. It should issue a helpful error message instead 2. jpackage fails to populate application image with Java runtime and app specific files when executed in Github but exits with "0" status indicating no error jpackage will successfully build platform-specific packages from any application image by design. It doesn't validate supplied application image to let users create platform specific packages from customized application images. It is no surprise for me that after adding "--name" to jpackage command line it worked. This supplied jpackage a package name that it would normally get from non-empty application image. The major problem in your use case is that jpackage doesn't create correct application image. Instead, it creates only a directory structure of application image, but no files and exits with a "success" status code. This is quite strange. Is there any chance Gradle ignores non-zero exit code from jpackage execution? Can you directly run jpackage command creating application image in the environment where it outputs "empty" application image and check its exit code (please add "--verbose" to jpackage command line to get debug output)? - Alexey On 4/7/2022 3:38 PM, Hiran Chaudhuri wrote: Hello Alex, thank you for coming back. We now have four different cases just for the second build step (appimage->deb). Let me first give you an overview: My Desktop (OpenJDK 16): My Command, Your command Github (OpenJDK 17): My command, Your command On Github I started using OpenJDK11, then switched to 16 and finally to 17. In respect to my build they all seem to behave the same. So I will give the status on all four of the combinations. And btw I use Gradle to trigger command lines which impacts a bit the log output but otherwise should not matter. --My Desktop, my command:-- Starting process 'command 'jpackage''. Working directory: /home/hiran/NetBeansProjects/settlers-installer/app Command: jpackage --app-image build/app-image/SettlersRemake --dest build/distributions --resource-dir build/resources/jpackage Successfully started process 'command 'jpackage'' :app:jpackagePhase2 (Thread[Execution worker for ':' Thread 3,5,main]) completed. Took 12.313 secs. This one runs reliably. I was a bit annoyed that the appdir directory is one level more than for build step 1 (input->appimage) - but maybe that is exactly because I did not specify --name. After all I have a Debian package that I can verify and install. --My Desktop, your command-- Starting process 'command 'jpackage''. Working directory: /home/hiran/NetBeansProjects/settlers-installer/app Command: jpackage --app-image build/app-image/SettlersRemake --dest build/distributions --resource-dir build/resources/jpackage Successfully started process 'command 'jpackage'' :app:jpackagePhase2 (Thread[Execution worker for ':' Thread 3,5,main]) completed. Took 12.313 secs. I added --name as you suggested. It seems I still need to specify the application name on the app-image parameter otherwise the build will fail. A bit strange since build step 1 was run with --dest build/app- image. I have not yet tested the Debian package yet. --Github, my command-- In build step 1 I am running jpackage like so: Starting process 'command 'jpackage''. Working directory: /home/runner/work/settlers-installer/settlers-installer/app Command: jpackage --type app-image --dest build/app-image -i build/jpackage_input/app-0.1.0-SNAPSHOT/lib --main-jar app-0.1.0- SNAPSHOT.jar --main-class settlers.installer.App --name SettlersRemake --app-version 0.1.0-SNAPSHOT --description Settlers 3 remake - see https://urldefense.com/v3/__https://github.com/__;!!ACWV5N9M2RV99hQ!csCrsY1mREmTYmH2eT2wnYjKhiYc2w5-kQMc9GrIoToruZ1Tz4GCYQ3O1a1_JKYyzRfj$ --vendor Hiran --icon build/resources/main/siedler3-helme-logo.png --resource-dir build/resources/jpackage Successfully started process 'command 'jpackage'' :app:jpackagePhase1 (Thread[Daemon worker,5,main]) completed. Took 12.919 secs. There is no error or any suspect message in stdout- Yet I investigated and found out that the app-image directory is almost empty. This is a problem for the second build step. And it is annoying that Gradle garbles the output with other stuff so I hope to have it separated correctly. :app:jpackagePhase2 (Thread[Daemon worker,5,main]) started. Bundler DEB Bundle failed because of java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null Task :app:jpackagePhase2 FAILED * What went wrong: Execution failed for task ':app:jpackagePhase2'. Process 'command 'jpackage'' finished with non-zero exit value 1 Since gradle is not logging the command it invoked I will give you that line from the build file: commandLine 'jpackage', '--app-image',
Re: RFR: 8265315: Support for CLDR version 41
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote: > This is to upgrade the CLDR data from version 39 to version 41 which was > released yesterday. The vast majority of the changes are basically replacing > the CLDR data, along with tools/testcase alignments. Here is the link to CLDR > v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41 Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8150
Re: RFR: 8283892: Compress and expand bits [v4]
On Thu, 7 Apr 2022 20:02:51 GMT, Alan Bateman wrote: >> Examples added in latest commit. > > I see you've added a comment on each example too, I think this really helpers > readers to see how they can be used. > > The class description of both Integer and Long have an implementation note > (they pre-date @implNote) referencing Hacker's Delight. We could potentially > expand the list of methods mentioned but it's not strictly necessary are they > are just examples. I also saw that on the class doc and considered the new methods fit neatly under the category of "bit twiddling" methods. - PR: https://git.openjdk.java.net/jdk/pull/8115
Re: RFR: 8265315: Support for CLDR version 41
On Thu, 7 Apr 2022 21:20:20 GMT, Naoto Sato wrote: > This is to upgrade the CLDR data from version 39 to version 41 which was > released yesterday. The vast majority of the changes are basically replacing > the CLDR data, along with tools/testcase alignments. Here is the link to CLDR > v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41 Marked as reviewed by joehw (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8150
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >> distinct. There are concepts that overlap in the two domains (public, >> private, etc.), others that only have a language-level modifier (sealed), >> and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these >> subtleties. For example, the bit positions used by access flags on different >> kinds of elements overlap (such as "volatile" for fields and "bridge" for >> methods. Just having a raw integer does not provide sufficient context to >> decode the corresponding language-level string. Methods like >> Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like >> Valhalla, addressing the existent modeling deficiency now ahead of time is >> reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. >> It is missing implementations to map from, say, method modifiers to access >> flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in >> once the API is further along. > > Joe Darcy 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 26 additional commits since > the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8266670 > - Make workding changes suggested in review feedback. > - Merge branch 'master' into JDK-8266670 > - Typo fix; add implSpec to Executable. > - Appease jcheck. > - Fix some bugs found by inspection, docs cleanup. > - Merge branch 'master' into JDK-8266670 > - Initial support for accessFlags methods > - Add mask to access flag functionality. > - ... and 16 more: > https://git.openjdk.java.net/jdk/compare/f55e4cdc...14980605 Keep-alive. - PR: https://git.openjdk.java.net/jdk/pull/7445
Re: fast way to infer caller
> > Hi Kasper, > > sorry to jump in here as an uninvolved onlooker, but I can't resist. > I really don't see why this should matter. Getting the caller class is a > rare edge case that you just do in exceptional situations; most often > it's more for debugging or something. > > What users really are interested in is high performance for standard > cases. Implementing a specific optimization into Hotspot to gain few > milliseconds is the least thing I expect from the JVM developers. > > I also don't understand why someone should instantiate a logger during > performance critical procedures. In more than 20 years of Java > development, I've never seen the need to create a logger on the fly. > They are *always* assigned to final static variables, or at least to > predefined pools. Everything else would be just wrong: To instantiate a > logger, you have to fetch at least the log level definition from some > configuration source, and this can never be fast. At least not that > we're talking about nanoseconds here. > > All logging implementations I know of (and all that make sense) are > highly optimized on log throughput; this can only be achieved by > preprocessing during initialization, why this is slow. But that doesn't > matter, because, as said, you should anyway create logger instances > beforehand. > > Sorry for the rant, but I really don't see the use case here. > Hi Michael, I don't really have an opinion on how you obtain a logger. But one particular use-case I've had was that I would like to perform some access checks based on the module of the caller. Something similar to how Panama checks for native access: Reflection.ensureNativeAccess(Reflection.getCallerClass()); You can implement something similar with StackWalker but it just adds a bit of non-negligible overhead to every invocation of the method. I'm pretty sure there must be other valid use cases out there where performance is important. After all, the StackWalker API was created because existing solutions such as Thread::getStackTrace weren't performant enough. /Kasper
RFR: 8265315: Support for CLDR version 41
This is to upgrade the CLDR data from version 39 to version 41 which was released yesterday. The vast majority of the changes are basically replacing the CLDR data, along with tools/testcase alignments. Here is the link to CLDR v41's release notes: https://cldr.unicode.org/index/downloads/cldr-41 - Commit messages: - Merge branch 'master' into cldr+ - CLDR v41 final - CLDR v41 beta2 - Merge branch 'master' into cldr+ - CLDR v41 alpha4 - Merge branch 'master' into cldr+ - Update copyright year to 2022 - CLDR release v40 - Merge branch 'master' into cldr - CLDR tip - ... and 11 more: https://git.openjdk.java.net/jdk/compare/526e7349...ee6985a4 Changes: https://git.openjdk.java.net/jdk/pull/8150/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8150=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265315 Stats: 132401 lines in 859 files changed: 96406 ins; 4216 del; 31779 mod Patch: https://git.openjdk.java.net/jdk/pull/8150.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8150/head:pull/8150 PR: https://git.openjdk.java.net/jdk/pull/8150
Re: fast way to infer caller
C and C++ are harder to read as a side effect of pre-processor macros. IMHO, Java's lack of pre-processor macros simplifies the language and improves readability. On 4/7/2022 9:01 PM, Ralph Goers wrote: > I mentioned this same concern back in 2017 when the Sun Reflection > class was removed. > > In Log4j’s case there are two places that accessing the stack comes into play: > 1. Obtaining a Logger . > 2. Logging an event and including the caller’s location information. > > To be honest, what sucks for Logging frameworks is that we really want > access to the location information at compile time such that the overhead > to include it would be zero. I’ve never understood why Java doesn’t include > it. > I wrote a Logging Framework for C back in the 1980’s that could include the > Information so this isn’t a new concept. > > Even if I could do > > logger.debug(System.location(), ….) > > Where System.location is replaced by the compiler with a constant object > would be a huge win. > > Ralph > > > >> On Apr 7, 2022, at 11:02 AM, Bernd Eckenfels wrote: >> >> Some loggers do need to find the location of the log statement (class and >> line where the logger is used not where it is instantiated). >> >> for those (it makes loggers more useful) getting the call site is time >> critical even if they are not in tight performance critical loops. >> >> But it actually does matter if/how the JVM optimizes such introspection.. if >> the JVM can inline (and maybe even constant intrinsic) the stalkwalker it >> would benefit such use cases just as well. >> >> -- >> https://bernd.eckenfels.net >> >> From: core-libs-dev on behalf of >> Michael Kuhlmann >> Sent: Thursday, April 7, 2022 7:55:16 PM >> To: core-libs-dev@openjdk.java.net >> Subject: Re: fast way to infer caller >> >> >> >> On 4/7/22 19:27, Kasper Nielsen wrote: nope, see my previous mail to Ceki, the VM is cheating here if it can inline the call to MethodHandles.lookup() >>> >>> Does how the VM cheats really matter? The fact is that the code in the JDK >>> can >>> get the calling class and implement something like MethodHandles.lookup() so >>> it takes ~3 ns. If you implemented something like a lookup class as a normal >>> user your best bet would be StackWalker.GetCallingClass() and you would end >>> up with something that is at least 2 magnitudes slower. That is probably not >>> an issue for most use cases. But for some, it might be a bit of a steep >>> cost. >>> >>> /Kasper >> >> Hi Kasper, >> >> sorry to jump in here as an uninvolved onlooker, but I can't resist. >> I really don't see why this should matter. Getting the caller class is a >> rare edge case that you just do in exceptional situations; most often >> it's more for debugging or something. >> >> What users really are interested in is high performance for standard >> cases. Implementing a specific optimization into Hotspot to gain few >> milliseconds is the least thing I expect from the JVM developers. >> >> I also don't understand why someone should instantiate a logger during >> performance critical procedures. In more than 20 years of Java >> development, I've never seen the need to create a logger on the fly. >> They are *always* assigned to final static variables, or at least to >> predefined pools. Everything else would be just wrong: To instantiate a >> logger, you have to fetch at least the log level definition from some >> configuration source, and this can never be fast. At least not that >> we're talking about nanoseconds here. >> >> All logging implementations I know of (and all that make sense) are >> highly optimized on log throughput; this can only be achieved by >> preprocessing during initialization, why this is slow. But that doesn't >> matter, because, as said, you should anyway create logger instances >> beforehand. >> >> Sorry for the rant, but I really don't see the use case here. > -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
Re: RFR: JDK-8281006 Module::getResourceAsStream should check if the resource is open unconditionally when caller is null [v3]
> Created a test called NullCallerGetResource to test
> Module::getResourceAsStream and Class::getResourceAsStream from the native
> level.
>
> At the java level the test builds a test module called 'n' which opens the
> package 'open' to everyone. There is also a package 'closed' which is neither
> opened or exported. Both packages have a text file called 'test.txt'. The
> open package has a class called OpenResources and the closed package has a
> class called ClosedResources. The native test is launched with the test
> module n added.
>
> At the native level the test tries to read both the open and closed resource
> from both the classes and the module. It performs the equivalent of the
> following java operations:
>
> Class c = open.OpenResources.fetchClass();
> InputStream in = c.getResourceAsStream("test.txt");
> assert(in != null); in.close();
>
> Module n = c.getModule();
> in = n.getResourceAsStream("open/test.txt");
> assert(in != null); in.close();
>
> Class closed = closed.ClosedResources.fetchClass();
> assert(closedsStream("test.txt") == null);
> assert(n.getResourceAsStream("closed/test.txt") == null);
>
> The test initially threw an NPE when trying to fetch the open resource. The
> Module class was fixed by removing the fragment with the (caller == null)
> test in getResourceAsStream, and changing the call to isOpen(String,Module)
> to use EVERYONE_MODULE if the caller module is null.
Tim Prinzing has updated the pull request incrementally with one additional
commit since the last revision:
revert Module::isOpen
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/8134/files
- new: https://git.openjdk.java.net/jdk/pull/8134/files/4b344e4d..912896d7
Webrevs:
- full: https://webrevs.openjdk.java.net/?repo=jdk=8134=02
- incr: https://webrevs.openjdk.java.net/?repo=jdk=8134=01-02
Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 mod
Patch: https://git.openjdk.java.net/jdk/pull/8134.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/8134/head:pull/8134
PR: https://git.openjdk.java.net/jdk/pull/8134
Re: fast way to infer caller
Perhaps https://bugs.openjdk.java.net/browse/JDK-4515935 for the MemoryHandler could be used to determine if StackWalker is fast enough for the lowest rung on the StackWalker performance ladder. Currently the MemoryHandler doesn't not infer the caller and the target handler sees the callsite of the thread that triggers the push. Most use cases of MemoryHandler are records that are loggable but, get discarded and never published to the target handler (never formatted nor sent to some data sink). So this is a real world use case of only openjdk classes. The Peabody fix I proposed in 2007 was to unconditionally force the caller to be computed prior to adding the LogRecord to the internal data structure. Therefore all loggable records would pay the cost of inferring the caller. Current code is fast and broken (assuming target formatter is showing callsite) and the correct code will be slower. If I were to redo that patch from Peabody I would think that PR review would bring to light a consistent view that StackWalker is fast enough at least the openjdk logging. Effectively defining the minimum performance standard. However, if it raises performance regression concerns perhaps there is some more work to be done improving StackWalker? :) Jason From: core-libs-dev on behalf of Bernd Eckenfels Sent: Thursday, April 7, 2022 1:02 PM To: core-libs-dev@openjdk.java.net Subject: Re: fast way to infer caller Some loggers do need to find the location of the log statement (class and line where the logger is used not where it is instantiated). for those (it makes loggers more useful) getting the call site is time critical even if they are not in tight performance critical loops. But it actually does matter if/how the JVM optimizes such introspection.. if the JVM can inline (and maybe even constant intrinsic) the stalkwalker it would benefit such use cases just as well. -- https://bernd.eckenfels.net From: core-libs-dev on behalf of Michael Kuhlmann Sent: Thursday, April 7, 2022 7:55:16 PM To: core-libs-dev@openjdk.java.net Subject: Re: fast way to infer caller On 4/7/22 19:27, Kasper Nielsen wrote: >> >> nope, see my previous mail to Ceki, the VM is cheating here if it can >> inline the call to MethodHandles.lookup() >> > > Does how the VM cheats really matter? The fact is that the code in the JDK > can > get the calling class and implement something like MethodHandles.lookup() so > it takes ~3 ns. If you implemented something like a lookup class as a normal > user your best bet would be StackWalker.GetCallingClass() and you would end > up with something that is at least 2 magnitudes slower. That is probably not > an issue for most use cases. But for some, it might be a bit of a steep > cost. > > /Kasper Hi Kasper, sorry to jump in here as an uninvolved onlooker, but I can't resist. I really don't see why this should matter. Getting the caller class is a rare edge case that you just do in exceptional situations; most often it's more for debugging or something. What users really are interested in is high performance for standard cases. Implementing a specific optimization into Hotspot to gain few milliseconds is the least thing I expect from the JVM developers. I also don't understand why someone should instantiate a logger during performance critical procedures. In more than 20 years of Java development, I've never seen the need to create a logger on the fly. They are *always* assigned to final static variables, or at least to predefined pools. Everything else would be just wrong: To instantiate a logger, you have to fetch at least the log level definition from some configuration source, and this can never be fast. At least not that we're talking about nanoseconds here. All logging implementations I know of (and all that make sense) are highly optimized on log throughput; this can only be achieved by preprocessing during initialization, why this is slow. But that doesn't matter, because, as said, you should anyway create logger instances beforehand. Sorry for the rant, but I really don't see the use case here.
Re: RFR: 8283892: Compress and expand bits [v4]
On Thu, 7 Apr 2022 18:23:50 GMT, Paul Sandoz wrote: >> src/java.base/share/classes/java/lang/Integer.java line 1781: >> >>> 1779: * All the upper remaining bits of the compressed value are set >>> 1780: * to zero. >>> 1781: * >> >> Following Alan's comment, I suggest the following examples: >> >> >> compress(0x9ABCDEF, 0x0F0F0FF) == 0xACEF >> compress(x, 1<>n & 1) >> compress(x, -1<>> n >> compress(m, m) == (m==-1||m==0)? m : (1<> compress(x, m) == compress(x & m, m) >> compress(expand(x, m), m) == x & compress(m, m) >> (compress(x, m) >>> n) & 1 == /*the bit of x corresponding to the nth set >> bit in m*/ >> >> >> …In two places. Similarly, examples for expand: >> >> >> expand(0x9ABCDEF, 0x0F0F0FF) == 0xC0D0EF >> expand(x, 1<> expand(x, -1<> expand(-1, m) == m >> expand(x, m) == expand(x, m) & m >> expand(compress(x, m), m) == x & m >> expand(1<> highest/lowestOneBit*/ >> >> >> (Please double check these examples!) > > Examples added in latest commit. I see you've added a comment on each example too, I think this really helpers readers to see how they can be used. The class description of both Integer and Long have an implementation note (they pre-date @implNote) referencing Hacker's Delight. We could potentially expand the list of methods mentioned but it's not strictly necessary are they are just examples. - PR: https://git.openjdk.java.net/jdk/pull/8115
Re: jpackage usage problems
Hello Alex, thank you for coming back. We now have four different cases just for the second build step (appimage->deb). Let me first give you an overview: My Desktop (OpenJDK 16): My Command, Your command Github (OpenJDK 17): My command, Your command On Github I started using OpenJDK11, then switched to 16 and finally to 17. In respect to my build they all seem to behave the same. So I will give the status on all four of the combinations. And btw I use Gradle to trigger command lines which impacts a bit the log output but otherwise should not matter. --My Desktop, my command:-- Starting process 'command 'jpackage''. Working directory: /home/hiran/NetBeansProjects/settlers-installer/app Command: jpackage --app-image build/app-image/SettlersRemake --dest build/distributions --resource-dir build/resources/jpackage Successfully started process 'command 'jpackage'' :app:jpackagePhase2 (Thread[Execution worker for ':' Thread 3,5,main]) completed. Took 12.313 secs. This one runs reliably. I was a bit annoyed that the appdir directory is one level more than for build step 1 (input->appimage) - but maybe that is exactly because I did not specify --name. After all I have a Debian package that I can verify and install. --My Desktop, your command-- Starting process 'command 'jpackage''. Working directory: /home/hiran/NetBeansProjects/settlers-installer/app Command: jpackage --app-image build/app-image/SettlersRemake --dest build/distributions --resource-dir build/resources/jpackage Successfully started process 'command 'jpackage'' :app:jpackagePhase2 (Thread[Execution worker for ':' Thread 3,5,main]) completed. Took 12.313 secs. I added --name as you suggested. It seems I still need to specify the application name on the app-image parameter otherwise the build will fail. A bit strange since build step 1 was run with --dest build/app- image. I have not yet tested the Debian package yet. --Github, my command-- In build step 1 I am running jpackage like so: Starting process 'command 'jpackage''. Working directory: /home/runner/work/settlers-installer/settlers-installer/app Command: jpackage --type app-image --dest build/app-image -i build/jpackage_input/app-0.1.0-SNAPSHOT/lib --main-jar app-0.1.0- SNAPSHOT.jar --main-class settlers.installer.App --name SettlersRemake --app-version 0.1.0-SNAPSHOT --description Settlers 3 remake - see https://github.com/ --vendor Hiran --icon build/resources/main/siedler3-helme-logo.png --resource-dir build/resources/jpackage Successfully started process 'command 'jpackage'' :app:jpackagePhase1 (Thread[Daemon worker,5,main]) completed. Took 12.919 secs. There is no error or any suspect message in stdout- Yet I investigated and found out that the app-image directory is almost empty. This is a problem for the second build step. And it is annoying that Gradle garbles the output with other stuff so I hope to have it separated correctly. :app:jpackagePhase2 (Thread[Daemon worker,5,main]) started. Bundler DEB Bundle failed because of java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null > Task :app:jpackagePhase2 FAILED * What went wrong: Execution failed for task ':app:jpackagePhase2'. > Process 'command 'jpackage'' finished with non-zero exit value 1 Since gradle is not logging the command it invoked I will give you that line from the build file: commandLine 'jpackage', '--app-image', 'build/app- image/SettlersRemake', '--dest', 'build', '--resource-dir', 'build/resources/jpackage' --Github, your command-- Since you suggested to add --name on the second step, the first step runs as it was before. And again most files are missing in the output. Starting process 'command 'jpackage''. Working directory: /home/runner/work/settlers-installer/settlers-installer/app Command: jpackage --type app-image --dest build/app-image -i build/jpackage_input/app-0.1.0-SNAPSHOT/lib --main-jar app-0.1.0-SNAPSHOT.jar --main-class settlers.installer.App --name SettlersRemake --app-version 0.1.0-SNAPSHOT --description Settlers 3 remake - see https://github.com/ --vendor Hiran --icon build/resources/main/siedler3-helme-logo.png --resource-dir build/resources/jpackage Successfully started process 'command 'jpackage'' :app:jpackagePhase1 (Thread[Execution worker for ':',5,main]) completed. Took 12.672 secs. To verify what files had been created I ran a 'find' afterwards. I had expected the full application, and the JDK runtime. But I only see these files for the appimage: build/app-image build/app-image/SettlersRemake build/app-image/SettlersRemake/lib build/app-image/SettlersRemake/bin build/app-image/SettlersRemake/bin/SettlersRemake With that, the second step is called and outputs this much: Starting process 'command 'jpackage''. Working directory: /home/runner/work/settlers-installer/settlers-installer/app Command: jpackage --app-image build/app-image/SettlersRemake --name SettlersRemake --dest build --resource-dir
Re: fast way to infer caller
I mentioned this same concern back in 2017 when the Sun Reflection class was removed. In Log4j’s case there are two places that accessing the stack comes into play: 1. Obtaining a Logger . 2. Logging an event and including the caller’s location information. To be honest, what sucks for Logging frameworks is that we really want access to the location information at compile time such that the overhead to include it would be zero. I’ve never understood why Java doesn’t include it. I wrote a Logging Framework for C back in the 1980’s that could include the Information so this isn’t a new concept. Even if I could do logger.debug(System.location(), ….) Where System.location is replaced by the compiler with a constant object would be a huge win. Ralph > On Apr 7, 2022, at 11:02 AM, Bernd Eckenfels wrote: > > Some loggers do need to find the location of the log statement (class and > line where the logger is used not where it is instantiated). > > for those (it makes loggers more useful) getting the call site is time > critical even if they are not in tight performance critical loops. > > But it actually does matter if/how the JVM optimizes such introspection.. if > the JVM can inline (and maybe even constant intrinsic) the stalkwalker it > would benefit such use cases just as well. > > -- > https://bernd.eckenfels.net > > From: core-libs-dev on behalf of > Michael Kuhlmann > Sent: Thursday, April 7, 2022 7:55:16 PM > To: core-libs-dev@openjdk.java.net > Subject: Re: fast way to infer caller > > > > On 4/7/22 19:27, Kasper Nielsen wrote: >>> >>> nope, see my previous mail to Ceki, the VM is cheating here if it can >>> inline the call to MethodHandles.lookup() >>> >> >> Does how the VM cheats really matter? The fact is that the code in the JDK >> can >> get the calling class and implement something like MethodHandles.lookup() so >> it takes ~3 ns. If you implemented something like a lookup class as a normal >> user your best bet would be StackWalker.GetCallingClass() and you would end >> up with something that is at least 2 magnitudes slower. That is probably not >> an issue for most use cases. But for some, it might be a bit of a steep >> cost. >> >> /Kasper > > Hi Kasper, > > sorry to jump in here as an uninvolved onlooker, but I can't resist. > I really don't see why this should matter. Getting the caller class is a > rare edge case that you just do in exceptional situations; most often > it's more for debugging or something. > > What users really are interested in is high performance for standard > cases. Implementing a specific optimization into Hotspot to gain few > milliseconds is the least thing I expect from the JVM developers. > > I also don't understand why someone should instantiate a logger during > performance critical procedures. In more than 20 years of Java > development, I've never seen the need to create a logger on the fly. > They are *always* assigned to final static variables, or at least to > predefined pools. Everything else would be just wrong: To instantiate a > logger, you have to fetch at least the log level definition from some > configuration source, and this can never be fast. At least not that > we're talking about nanoseconds here. > > All logging implementations I know of (and all that make sense) are > highly optimized on log throughput; this can only be achieved by > preprocessing during initialization, why this is slow. But that doesn't > matter, because, as said, you should anyway create logger instances > beforehand. > > Sorry for the rant, but I really don't see the use case here.
Re: RFR: 8284036: Make ConcurrentHashMap.CollectionView a sealed hierarchy
On Mon, 4 Apr 2022 06:55:10 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which now marks `CollectionView` as > a `sealed` class with only `EntrySetView`, `KeySetView` and `ValuesView` as > the sub-classes? This change corresponds to > https://bugs.openjdk.java.net/browse/JDK-8284036. > > A CSR has also been drafted for this change > https://bugs.openjdk.java.net/browse/JDK-8284272. As noted in the CSR, > marking this class as `sealed` and marking `KeySetView` as `final` shouldn't > have any impact in general and also in context of > serialization/de-serialization. > > tier1, tier2, tier3 tests have been run successfully with this change. LGTM - Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8085
Re: RFR: 8283892: Compress and expand bits [v4]
On Wed, 6 Apr 2022 18:22:45 GMT, John R Rose wrote: >> Paul Sandoz has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Fix typo. >> - Provide examples. > > src/java.base/share/classes/java/lang/Integer.java line 1781: > >> 1779: * All the upper remaining bits of the compressed value are set >> 1780: * to zero. >> 1781: * > > Following Alan's comment, I suggest the following examples: > > > compress(0x9ABCDEF, 0x0F0F0FF) == 0xACEF > compress(x, 1<>n & 1) > compress(x, -1<>> n > compress(m, m) == (m==-1||m==0)? m : (1< compress(x, m) == compress(x & m, m) > compress(expand(x, m), m) == x & compress(m, m) > (compress(x, m) >>> n) & 1 == /*the bit of x corresponding to the nth set > bit in m*/ > > > …In two places. Similarly, examples for expand: > > > expand(0x9ABCDEF, 0x0F0F0FF) == 0xC0D0EF > expand(x, 1< expand(x, -1< expand(-1, m) == m > expand(x, m) == expand(x, m) & m > expand(compress(x, m), m) == x & m > expand(1< highest/lowestOneBit*/ > > > (Please double check these examples!) Examples added in latest commit. - PR: https://git.openjdk.java.net/jdk/pull/8115
Re: RFR: 8283892: Compress and expand bits [v4]
> Add support to compress bits and expand bits of `int` and `long` values, see > Hacker's Delight (2nd edition), section 7.4. > > Compressing or expanding bits of an `int` or `long` value can be composed to > enable general permutations, and the "sheep and goats" operation (SAG) see > Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a > stable binary radix sort. > > The compress and expand functionality maps efficiently to hardware > instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the > implementations can be very efficient on supporting hardware. > Intrinsification will occur in a separate PR. > > This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the > beneficial performance impact of the `PDEP` instruction, and by extension the > `expand` method, when applied to the implementation of a bit-vector select > operation in succinct data structures (for example `select(r)` returns the > position of the `r`th 1). > > Testing-wise the approach take is three fold: > 1. Tests compared against simple implementations that are easy to read and > verify against the JDK implementations (which later will also be made > intrinsic). To compensate all tests are also run flipping the test methods > and the methods under test. > 2. Tests composed of compress and expand and vice versa. > 3. Tests with known mask patterns, whose expected values are easily derived > from the inputs. Paul Sandoz has updated the pull request incrementally with two additional commits since the last revision: - Fix typo. - Provide examples. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8115/files - new: https://git.openjdk.java.net/jdk/pull/8115/files/da49874b..96d90e1a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8115=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8115=02-03 Stats: 186 lines in 2 files changed: 186 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8115.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8115/head:pull/8115 PR: https://git.openjdk.java.net/jdk/pull/8115
Re: jpackage usage problems
Hi Hiran, My apologies for not replying to your previous email. In that particular case the problem seems to be in missing "--name" cli option on the second jpackage command line ($JAVA_HOME/bin/jpackage --app-image build/app-image --verbose --dest build) that is supposed to build .deb package from the app image. Could you please confirm this is the case so I can file more specific description in a CR tracking this issue. Do you have a stack trace for the second NPE? It would help to understand what went wrong. Issue with the Github Runner looks similar to this one [1] [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-March/086656.html - Alexey On 4/7/2022 2:57 AM, Hiran Chaudhuri wrote: Hi there. I have another case where running jpackage emits Bundler DEB Bundle failed because of java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null I have never experienced NullPointerExceptions in other JDK tools. Seems to me JPackage is a new kid on the block. In this case, JPackage is invoked to finish from an existing appimage to the final package. the failure is caused because some important files are missing in appimage. The previous run is even more puzzling for me. It is supposed to create the appimage directory. And while it emits no error message, on my development machine it runs reliably while on the Github Runner it just does not create all files - no error message, no exit code - nothing. Any idea what I could be looking at? Hiran On Mon, 2022-04-04 at 08:49 +0200, Hiran Chaudhuri wrote: Hello Alex, I tried running the same command with the jdk19 you pointed at. As a first, I get this output: $JAVA_HOME/bin/jpackage --version 19-ea With that, I invoked the command as before, and i fairly got the same output. So the behaviour in the latest version has not changed. Two things I'd like to point out: - there is no JPackage version in the output itself so both you and me have to trust the correct one was called - I found out the mistake: I should have used --app-image build/app-image/SettlersRemake but JPackage gave a warning in the beginning and processed all the rest Hiran $JAVA_HOME/bin/jpackage --app-image build/app-image --verbose --dest build [08:41:58.675] Warning: app-image dir not generated by jpackage. [08:41:58.688] Running dpkg [08:41:58.696] Command [PID: 21712]: dpkg --print-architecture [08:41:58.696] Output: amd64 [08:41:58.698] Returned: 0 [08:41:58.702] Running dpkg [08:41:58.719] Command [PID: 21714]: dpkg -s coreutils [08:41:58.719] Output: Package: coreutils Essential: yes Status: install ok installed Priority: required Section: utils Installed-Size: 7196 Maintainer: Ubuntu Developers < ubuntu-devel-disc...@lists.ubuntu.com> Architecture: amd64 Multi-Arch: foreign Version: 8.30-3ubuntu2 Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>= 2.28), libselinux1 (>= 2.1.13) Description: GNU core utilities This package contains the basic file, shell and text manipulation utilities which are expected to exist on every operating system. . Specifically, this package includes: arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false flock fmt fold groups head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes Homepage: http://gnu.org/software/coreutils Original-Maintainer: Michael Stone [08:41:58.719] Returned: 0 [08:41:58.720] Running dpkg-deb [08:41:58.722] Warning: app-image dir not generated by jpackage. [08:41:58.723] Warning: app-image dir not generated by jpackage. [08:41:58.723] java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null at java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769) at java.base/java.util.regex.Matcher.reset(Matcher.java:415) at java.base/java.util.regex.Matcher.(Matcher.java:252) at java.base/java.util.regex.Pattern.matcher(Pattern.java:1144) at jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Li nu xDebBundler.java:84) at jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(Linux Pa ckageBundler.java:72) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments .j ava:688) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Argumen ts .java:561) at
Re: fast way to infer caller
Some loggers do need to find the location of the log statement (class and line where the logger is used not where it is instantiated). for those (it makes loggers more useful) getting the call site is time critical even if they are not in tight performance critical loops. But it actually does matter if/how the JVM optimizes such introspection.. if the JVM can inline (and maybe even constant intrinsic) the stalkwalker it would benefit such use cases just as well. -- https://bernd.eckenfels.net From: core-libs-dev on behalf of Michael Kuhlmann Sent: Thursday, April 7, 2022 7:55:16 PM To: core-libs-dev@openjdk.java.net Subject: Re: fast way to infer caller On 4/7/22 19:27, Kasper Nielsen wrote: >> >> nope, see my previous mail to Ceki, the VM is cheating here if it can >> inline the call to MethodHandles.lookup() >> > > Does how the VM cheats really matter? The fact is that the code in the JDK > can > get the calling class and implement something like MethodHandles.lookup() so > it takes ~3 ns. If you implemented something like a lookup class as a normal > user your best bet would be StackWalker.GetCallingClass() and you would end > up with something that is at least 2 magnitudes slower. That is probably not > an issue for most use cases. But for some, it might be a bit of a steep > cost. > > /Kasper Hi Kasper, sorry to jump in here as an uninvolved onlooker, but I can't resist. I really don't see why this should matter. Getting the caller class is a rare edge case that you just do in exceptional situations; most often it's more for debugging or something. What users really are interested in is high performance for standard cases. Implementing a specific optimization into Hotspot to gain few milliseconds is the least thing I expect from the JVM developers. I also don't understand why someone should instantiate a logger during performance critical procedures. In more than 20 years of Java development, I've never seen the need to create a logger on the fly. They are *always* assigned to final static variables, or at least to predefined pools. Everything else would be just wrong: To instantiate a logger, you have to fetch at least the log level definition from some configuration source, and this can never be fast. At least not that we're talking about nanoseconds here. All logging implementations I know of (and all that make sense) are highly optimized on log throughput; this can only be achieved by preprocessing during initialization, why this is slow. But that doesn't matter, because, as said, you should anyway create logger instances beforehand. Sorry for the rant, but I really don't see the use case here.
Re: fast way to infer caller
On 4/7/22 19:27, Kasper Nielsen wrote: nope, see my previous mail to Ceki, the VM is cheating here if it can inline the call to MethodHandles.lookup() Does how the VM cheats really matter? The fact is that the code in the JDK can get the calling class and implement something like MethodHandles.lookup() so it takes ~3 ns. If you implemented something like a lookup class as a normal user your best bet would be StackWalker.GetCallingClass() and you would end up with something that is at least 2 magnitudes slower. That is probably not an issue for most use cases. But for some, it might be a bit of a steep cost. /Kasper Hi Kasper, sorry to jump in here as an uninvolved onlooker, but I can't resist. I really don't see why this should matter. Getting the caller class is a rare edge case that you just do in exceptional situations; most often it's more for debugging or something. What users really are interested in is high performance for standard cases. Implementing a specific optimization into Hotspot to gain few milliseconds is the least thing I expect from the JVM developers. I also don't understand why someone should instantiate a logger during performance critical procedures. In more than 20 years of Java development, I've never seen the need to create a logger on the fly. They are *always* assigned to final static variables, or at least to predefined pools. Everything else would be just wrong: To instantiate a logger, you have to fetch at least the log level definition from some configuration source, and this can never be fast. At least not that we're talking about nanoseconds here. All logging implementations I know of (and all that make sense) are highly optimized on log throughput; this can only be achieved by preprocessing during initialization, why this is slow. But that doesn't matter, because, as said, you should anyway create logger instances beforehand. Sorry for the rant, but I really don't see the use case here.
Re: fast way to infer caller
> > nope, see my previous mail to Ceki, the VM is cheating here if it can > inline the call to MethodHandles.lookup() > Does how the VM cheats really matter? The fact is that the code in the JDK can get the calling class and implement something like MethodHandles.lookup() so it takes ~3 ns. If you implemented something like a lookup class as a normal user your best bet would be StackWalker.GetCallingClass() and you would end up with something that is at least 2 magnitudes slower. That is probably not an issue for most use cases. But for some, it might be a bit of a steep cost. /Kasper
Re: RFR: 8283892: Compress and expand bits [v3]
> Add support to compress bits and expand bits of `int` and `long` values, see > Hacker's Delight (2nd edition), section 7.4. > > Compressing or expanding bits of an `int` or `long` value can be composed to > enable general permutations, and the "sheep and goats" operation (SAG) see > Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a > stable binary radix sort. > > The compress and expand functionality maps efficiently to hardware > instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the > implementations can be very efficient on supporting hardware. > Intrinsification will occur in a separate PR. > > This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the > beneficial performance impact of the `PDEP` instruction, and by extension the > `expand` method, when applied to the implementation of a bit-vector select > operation in succinct data structures (for example `select(r)` returns the > position of the `r`th 1). > > Testing-wise the approach take is three fold: > 1. Tests compared against simple implementations that are easy to read and > verify against the JDK implementations (which later will also be made > intrinsic). To compensate all tests are also run flipping the test methods > and the methods under test. > 2. Tests composed of compress and expand and vice versa. > 3. Tests with known mask patterns, whose expected values are easily derived > from the inputs. Paul Sandoz has updated the pull request incrementally with five additional commits since the last revision: - Merge remote-tracking branch 'cl4es/expand_a_bit_more' into compress-expand-bits - Rename partx -> maskPrefixx, add ForceInline - Fix copy-paste error in Long.expand - Add microbenchmarks and manually unroll expand implementations - Consistent bounds. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8115/files - new: https://git.openjdk.java.net/jdk/pull/8115/files/8c536de6..da49874b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8115=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8115=01-02 Stats: 163 lines in 5 files changed: 107 ins; 11 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/8115.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8115/head:pull/8115 PR: https://git.openjdk.java.net/jdk/pull/8115
Integrated: JDK-8234128 jarsigner will not show not-signed-by-alias warning if an intermediate cert is in this keystore
On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers wrote: > https://bugs.openjdk.java.net/browse/JDK-8234128 > > My initial attempt had too many bad side-effects. This latest fix only tries > to suppress the warning message. This pull request has now been integrated. Changeset: d6f01e9d Author:Mark Powers Committer: Jamil Nimeh URL: https://git.openjdk.java.net/jdk/commit/d6f01e9d6f35fb235d9b9fb674867c9760b1c1d1 Stats: 101 lines in 2 files changed: 99 ins; 0 del; 2 mod 8234128: jarsigner will not show not-signed-by-alias warning if an intermediate cert is in this keystore Reviewed-by: jnimeh - PR: https://git.openjdk.java.net/jdk/pull/7751
Re: RFR: JDK-8281006 Module::getResourceAsStream should check if the resource is open unconditionally when caller is null [v2]
On Thu, 7 Apr 2022 05:52:24 GMT, Alan Bateman wrote: > Tim - this creates a conflict between the spec and implementation, the > changes to the 2-arg isOpen method need to be dropped so that it continues to > throw NPE if module is null. okay - PR: https://git.openjdk.java.net/jdk/pull/8134
Re: RFR: JDK-8234128 jarsigner will not show not-signed-by-alias warning if an intermediate cert is in this keystore
On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers wrote: > https://bugs.openjdk.java.net/browse/JDK-8234128 > > My initial attempt had too many bad side-effects. This latest fix only tries > to suppress the warning message. Looks good to me. Yeah, the loop seems like it would behave the same way with or without the intermediate CA cert for the purposes of the warning message. I'm good with it. - Marked as reviewed by jnimeh (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7751
Re: RFR: JDK-8234128 jarsigner will not show not-signed-by-alias warning if an intermediate cert is in this keystore
On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers wrote: > https://bugs.openjdk.java.net/browse/JDK-8234128 > > My initial attempt had too many bad side-effects. This latest fix only tries > to suppress the warning message. I recall that Max said the intermediate was not necessary. Maybe he can chime in. - PR: https://git.openjdk.java.net/jdk/pull/7751
Integrated: 8284444: Sting typo
On Wed, 6 Apr 2022 12:07:30 GMT, Daniel Jeliński wrote: > This patch adds missing `r` in `string`s This pull request has now been integrated. Changeset: 5bafcfdc Author:Daniel Jeliński URL: https://git.openjdk.java.net/jdk/commit/5bafcfdc171b5a514ecf620703e77fa2f4a49c58 Stats: 10 lines in 5 files changed: 0 ins; 0 del; 10 mod 828: Sting typo Reviewed-by: kcr, aivanov, mgronlun - PR: https://git.openjdk.java.net/jdk/pull/8125
Re: RFR: 8283892: Compress and expand bits [v2]
On Thu, 7 Apr 2022 14:01:53 GMT, Claes Redestad wrote: >> Paul Sandoz has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Doc and test updates. > > I experimented with this and drafted a few microbenchmarks along and a > micro-optimization to the expand methods (see #8146). Up to you, but I think > it makes sense to consider such optimizations to the plain java > implementation given that 1) not all platforms have specialized instructions > where an intrinsic will make sense and 2) it appears to be a boost to warmup. @cl4es thanks, your changes to `expand` looks reasonable, given the array allocation cost. - PR: https://git.openjdk.java.net/jdk/pull/8115
Re: RFR: 8283892: Compress and expand bits [v2]
On Wed, 6 Apr 2022 17:39:48 GMT, John R Rose wrote:
>> Paul Sandoz has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Doc and test updates.
>
> test/jdk/java/lang/AbstractCompressExpandTest.java line 145:
>
>> 143:
>> 144: int i = 0;
>> 145: for (int len = 0; len < 32; len++) {
>
> Lengths should be `len = 1; len <= 32; len++`, generating fewer redundant
> zero-length masks and a full-length -1 mask. The pos should be `pos = 0; pos
> <= 32 - len; pos++`, generating fully left-justified masks of the form
> `-1<
> Also, you should generate a zero-mask, just once. I think initializing `int
> i = 1` will do that trick.
>
> (Same comment in two places.)
Done.
-
PR: https://git.openjdk.java.net/jdk/pull/8115
Re: RFR: JDK-8234128 jarsigner will not show not-signed-by-alias warning if an intermediate cert is in this keystore
On Tue, 8 Mar 2022 23:22:56 GMT, Mark Powers wrote: > https://bugs.openjdk.java.net/browse/JDK-8234128 > > My initial attempt had too many bad side-effects. This latest fix only tries > to suppress the warning message. test/jdk/sun/security/tools/jarsigner/warnings/AliasNotInStoreTest2.java line 50: > 48: > 49: createAlias(CA_KEY_ALIAS, "-ext", "bc"); > 50: createAlias(FIRST_KEY_ALIAS); Is this creating a 3-cert chain (signer -> intermediate -> trust anchor) or just a 2-cert chain (signer -> trust anchor)? I ask because the bug description specifies that it requires a missing signer alias but an intermediate CA being present (and I assume the TA as well). This looks like it's creating a 2-cert chain. From looking at the loop in intKeyStoreForOneSigner perhaps it doesn't matter and a 2-cert is just as good as a 3-cert chain. - PR: https://git.openjdk.java.net/jdk/pull/7751
Re: RFR: 8283892: Compress and expand bits [v2]
On Wed, 6 Apr 2022 21:57:44 GMT, Paul Sandoz wrote: >> Add support to compress bits and expand bits of `int` and `long` values, see >> Hacker's Delight (2nd edition), section 7.4. >> >> Compressing or expanding bits of an `int` or `long` value can be composed to >> enable general permutations, and the "sheep and goats" operation (SAG) see >> Hacker's Delight (2nd edition), section 7.7. SAG can be used to perform a >> stable binary radix sort. >> >> The compress and expand functionality maps efficiently to hardware >> instructions, such as `PEXT` and `PDEP` on x86 hardware. Thus the >> implementations can be very efficient on supporting hardware. >> Intrinsification will occur in a separate PR. >> >> This [paper](https://arxiv.org/pdf/1706.00990.pdf) investigates the >> beneficial performance impact of the `PDEP` instruction, and by extension >> the `expand` method, when applied to the implementation of a bit-vector >> select operation in succinct data structures (for example `select(r)` >> returns the position of the `r`th 1). >> >> Testing-wise the approach take is three fold: >> 1. Tests compared against simple implementations that are easy to read and >> verify against the JDK implementations (which later will also be made >> intrinsic). To compensate all tests are also run flipping the test methods >> and the methods under test. >> 2. Tests composed of compress and expand and vice versa. >> 3. Tests with known mask patterns, whose expected values are easily derived >> from the inputs. > > Paul Sandoz has updated the pull request incrementally with one additional > commit since the last revision: > > Doc and test updates. I experimented with this and drafted a few microbenchmarks along and a micro-optimization to the expand methods (see #8146). Up to you, but I think it makes sense to consider such optimizations to the plain java implementation given that 1) not all platforms have specialized instructions where an intrinsic will make sense and 2) it appears to be a boost to warmup. - PR: https://git.openjdk.java.net/jdk/pull/8115
Re: fast way to infer caller
Rémi, Jason, Steven, Kasper, Thank you all for your thoughtful feedback. I forgot to mention that in addition to obtaining the appropriate logger by inferring caller class, the caller class may also be a data point written with each logging event, aka LogRecord. If the cost of writing a log event to file is 500 nanoseconds (without caller data), spending additional 1800 nanoseconds to obtain caller data via StackWalker reduces throughput by a factor of 4.8. Mind you, this is still much better than obtaining caller data via "new Throwable().getStackTrace();" which costs about 11'000 nanoseconds, reducing throughput by a factor of 24. While logging 2'000'000 messages per second is not a goal, reducing the cost of logging as much as possible, is a worthwhile goal. At present time, retrieving caller data still has a significant effect on logging performance. -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch
Re: fast way to infer caller
> From: "Kasper Nielsen"
> To: "Remi Forax"
> Cc: "Ceki Gülcü" , "core-libs-dev"
>
> Sent: Thursday, April 7, 2022 2:42:46 PM
> Subject: Re: fast way to infer caller
> On Thu, 7 Apr 2022 at 13:33, Remi Forax < [ mailto:fo...@univ-mlv.fr |
> fo...@univ-mlv.fr ] > wrote:
>> - Original Message -
>> > From: "Kasper Nielsen" < [ mailto:kaspe...@gmail.com | kaspe...@gmail.com
>> > ] >
>> > To: "Ceki Gülcü" < [ mailto:c...@qos.ch | c...@qos.ch ] >
>>> Cc: "core-libs-dev" < [ mailto:core-libs-dev@openjdk.java.net |
>> > core-libs-dev@openjdk.java.net ] >
>> > Sent: Thursday, April 7, 2022 1:53:33 PM
>> > Subject: Re: fast way to infer caller
>> >> MethodHandles.lookup().lookupClass() looks very promising except that
>> >> there is no way to specify the depth.
>> >> I am looking for a method to obtain the Nth caller at a cost of around
>> >> 100 to 200 nanoseconds of CPU time. Do you think the JDK could cater
>> >> for this use case?
>> > Hi Ceki,
>> > I don't think you will find the numbers you are looking for with
>> > StackWalker.
>> > Compared to something like Reflection.getCallerClass() which
>> > MethodHandles.lookup() uses.
>> > There is still a very large (>100x) performance gap between the two.
>> > public class StackWalkerPerf {
>> > static final StackWalker sw =
>> > StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE);
>> > @Benchmark
>> > public Class stackWalkerCallerClass() {
>> > return sw.getCallerClass();
>> > }
>> > @Benchmark
>> > public Class reflectionCallerClass() {
>> > return MethodHandles.lookup().lookupClass();
>> > }
>> > }
>> > Benchmark Mode Cnt Score Error Units
>> > StackWalkerPerf.reflectionCallerClass avgt 10 2,927 ± 0,012 ns/op
>> > StackWalkerPerf.stackWalkerCallerClass avgt 10 915,287 ± 9,565 ns/op
>>> The resulting class is not the same, so comparing the performance of two
>>> codes
>> > that does not do the same thing is dubious, no ?
> I think it is a fair test. MethodHandles.lookup() is basically just wrapping
> Reflection.getCallerClass(). So if anything
> calling Reflection.getCallerClass() directly would be even faster than calling
> MethodHandles.lookup().lookupClass();
nope, see my previous mail to Ceki, the VM is cheating here if it can inline
the call to MethodHandles.lookup().
> /Kasper
Rémi
Re: RFR: JDK-8281006 Module::getResourceAsStream should check if the resource is open unconditionally when caller is null [v2]
On Thu, 7 Apr 2022 00:56:42 GMT, Tim Prinzing wrote:
>> Created a test called NullCallerGetResource to test
>> Module::getResourceAsStream and Class::getResourceAsStream from the native
>> level.
>>
>> At the java level the test builds a test module called 'n' which opens the
>> package 'open' to everyone. There is also a package 'closed' which is
>> neither opened or exported. Both packages have a text file called
>> 'test.txt'. The open package has a class called OpenResources and the closed
>> package has a class called ClosedResources. The native test is launched with
>> the test module n added.
>>
>> At the native level the test tries to read both the open and closed resource
>> from both the classes and the module. It performs the equivalent of the
>> following java operations:
>>
>> Class c = open.OpenResources.fetchClass();
>> InputStream in = c.getResourceAsStream("test.txt");
>> assert(in != null); in.close();
>>
>> Module n = c.getModule();
>> in = n.getResourceAsStream("open/test.txt");
>> assert(in != null); in.close();
>>
>> Class closed = closed.ClosedResources.fetchClass();
>> assert(closedsStream("test.txt") == null);
>> assert(n.getResourceAsStream("closed/test.txt") == null);
>>
>> The test initially threw an NPE when trying to fetch the open resource. The
>> Module class was fixed by removing the fragment with the (caller == null)
>> test in getResourceAsStream, and changing the call to isOpen(String,Module)
>> to use EVERYONE_MODULE if the caller module is null.
>
> Tim Prinzing has updated the pull request incrementally with one additional
> commit since the last revision:
>
> update copyright date
Build change looks good.
-
Marked as reviewed by erikj (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/8134
Re: fast way to infer caller
On Thu, 7 Apr 2022 at 13:33, Remi Forax wrote:
> - Original Message -
> > From: "Kasper Nielsen"
> > To: "Ceki Gülcü"
> > Cc: "core-libs-dev"
> > Sent: Thursday, April 7, 2022 1:53:33 PM
> > Subject: Re: fast way to infer caller
>
> >>
> >> MethodHandles.lookup().lookupClass() looks very promising except that
> >> there is no way to specify the depth.
> >>
> >> I am looking for a method to obtain the Nth caller at a cost of around
> >> 100 to 200 nanoseconds of CPU time. Do you think the JDK could cater
> >> for this use case?
> >>
> >
> > Hi Ceki,
> >
> > I don't think you will find the numbers you are looking for with
> > StackWalker.
> > Compared to something like Reflection.getCallerClass() which
> > MethodHandles.lookup() uses.
> > There is still a very large (>100x) performance gap between the two.
> >
> > public class StackWalkerPerf {
> >
> >static final StackWalker sw =
> > StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE);
> >
> >@Benchmark
> >public Class stackWalkerCallerClass() {
> >return sw.getCallerClass();
> >}
> >
> >@Benchmark
> >public Class reflectionCallerClass() {
> >return MethodHandles.lookup().lookupClass();
> >}
> > }
> >
> > Benchmark Mode Cnt ScoreError
> Units
> > StackWalkerPerf.reflectionCallerClass avgt 102,927 ± 0,012 ns/op
> > StackWalkerPerf.stackWalkerCallerClass avgt 10 915,287 ± 9,565 ns/op
>
> > The resulting class is not the same, so comparing the performance of two
> codes that does not do the same thing is dubious, no ?
I think it is a fair test. MethodHandles.lookup() is basically just
wrapping Reflection.getCallerClass(). So if anything
calling Reflection.getCallerClass() directly would be even faster than
calling MethodHandles.lookup().lookupClass();
/Kasper
Re: fast way to infer caller
- Original Message -
> From: "Kasper Nielsen"
> To: "Ceki Gülcü"
> Cc: "core-libs-dev"
> Sent: Thursday, April 7, 2022 1:53:33 PM
> Subject: Re: fast way to infer caller
>>
>> MethodHandles.lookup().lookupClass() looks very promising except that
>> there is no way to specify the depth.
>>
>> I am looking for a method to obtain the Nth caller at a cost of around
>> 100 to 200 nanoseconds of CPU time. Do you think the JDK could cater
>> for this use case?
>>
>
> Hi Ceki,
>
> I don't think you will find the numbers you are looking for with
> StackWalker.
> Compared to something like Reflection.getCallerClass() which
> MethodHandles.lookup() uses.
> There is still a very large (>100x) performance gap between the two.
>
> public class StackWalkerPerf {
>
>static final StackWalker sw =
> StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE);
>
>@Benchmark
>public Class stackWalkerCallerClass() {
>return sw.getCallerClass();
>}
>
>@Benchmark
>public Class reflectionCallerClass() {
>return MethodHandles.lookup().lookupClass();
>}
> }
>
> Benchmark Mode Cnt ScoreError Units
> StackWalkerPerf.reflectionCallerClass avgt 102,927 ± 0,012 ns/op
> StackWalkerPerf.stackWalkerCallerClass avgt 10 915,287 ± 9,565 ns/op
The resulting class is not the same, so comparing the performance of two codes
that does not do the same thing is dubious, no ?
>
> /Kasper
Rémi
Re: fast way to infer caller
>
> MethodHandles.lookup().lookupClass() looks very promising except that
> there is no way to specify the depth.
>
> I am looking for a method to obtain the Nth caller at a cost of around
> 100 to 200 nanoseconds of CPU time. Do you think the JDK could cater
> for this use case?
>
Hi Ceki,
I don't think you will find the numbers you are looking for with
StackWalker.
Compared to something like Reflection.getCallerClass() which
MethodHandles.lookup() uses.
There is still a very large (>100x) performance gap between the two.
public class StackWalkerPerf {
static final StackWalker sw =
StackWalker.getInstance(Option.RETAIN_CLASS_REFERENCE);
@Benchmark
public Class stackWalkerCallerClass() {
return sw.getCallerClass();
}
@Benchmark
public Class reflectionCallerClass() {
return MethodHandles.lookup().lookupClass();
}
}
Benchmark Mode Cnt ScoreError Units
StackWalkerPerf.reflectionCallerClass avgt 102,927 ± 0,012 ns/op
StackWalkerPerf.stackWalkerCallerClass avgt 10 915,287 ± 9,565 ns/op
/Kasper
Re: RFR: 8284036: Make ConcurrentHashMap.CollectionView a sealed hierarchy
On Mon, 4 Apr 2022 06:55:10 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which now marks `CollectionView` as > a `sealed` class with only `EntrySetView`, `KeySetView` and `ValuesView` as > the sub-classes? This change corresponds to > https://bugs.openjdk.java.net/browse/JDK-8284036. > > A CSR has also been drafted for this change > https://bugs.openjdk.java.net/browse/JDK-8284272. As noted in the CSR, > marking this class as `sealed` and marking `KeySetView` as `final` shouldn't > have any impact in general and also in context of > serialization/de-serialization. > > tier1, tier2, tier3 tests have been run successfully with this change. OK. I don't have any objections to doing this. - PR: https://git.openjdk.java.net/jdk/pull/8085
Re: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v9]
> Despite the hash value being cached for Strings, computing the hash still > represents a significant CPU usage for applications handling lots of text. > > Even though it would be generally better to do it through an enhancement to > the autovectorizer, the complexity of doing it by hand is trivial and the > gain is sizable (2x speedup) even without the Vector API. The algorithm has > been proposed by Richard Startin and Paul Sandoz [1]. > > Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` > > > Benchmark(size) Mode Cnt Score > Error Units > StringHashCode.Algorithm.scalarLatin1 0 avgt 25 2.111 > ± 0.210 ns/op > StringHashCode.Algorithm.scalarLatin1 1 avgt 25 3.500 > ± 0.127 ns/op > StringHashCode.Algorithm.scalarLatin110 avgt 25 7.001 > ± 0.099 ns/op > StringHashCode.Algorithm.scalarLatin1 100 avgt 2561.285 > ± 0.444 ns/op > StringHashCode.Algorithm.scalarLatin1 1000 avgt 25 628.995 > ± 0.846 ns/op > StringHashCode.Algorithm.scalarLatin1 1 avgt 25 6307.990 > ± 4.071 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled16 0 avgt 25 2.358 > ± 0.092 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled16 1 avgt 25 3.631 > ± 0.159 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled16 10 avgt 25 7.049 > ± 0.019 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled16 100 avgt 2533.626 > ± 1.218 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled161000 avgt 25 317.811 > ± 1.225 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled16 1 avgt 25 3212.333 > ± 14.621 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled80 avgt 25 2.356 > ± 0.097 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled81 avgt 25 3.630 > ± 0.158 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled8 10 avgt 25 8.724 > ± 0.065 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled8 100 avgt 2532.402 > ± 0.019 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled8 1000 avgt 25 321.949 > ± 0.251 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled81 avgt 25 3202.083 > ± 1.667 ns/op > StringHashCode.Algorithm.scalarUTF16 0 avgt 25 2.135 > ± 0.191 ns/op > StringHashCode.Algorithm.scalarUTF16 1 avgt 25 5.202 > ± 0.362 ns/op > StringHashCode.Algorithm.scalarUTF16 10 avgt 2511.105 > ± 0.112 ns/op > StringHashCode.Algorithm.scalarUTF16100 avgt 2575.974 > ± 0.702 ns/op > StringHashCode.Algorithm.scalarUTF16 1000 avgt 25 716.429 > ± 3.290 ns/op > StringHashCode.Algorithm.scalarUTF16 1 avgt 25 7095.459 > ± 43.847 ns/op > StringHashCode.Algorithm.scalarUTF16Unrolled160 avgt 25 2.381 > ± 0.038 ns/op > StringHashCode.Algorithm.scalarUTF16Unrolled161 avgt 25 5.268 > ± 0.422 ns/op > StringHashCode.Algorithm.scalarUTF16Unrolled16 10 avgt 2511.248 > ± 0.178 ns/op > StringHashCode.Algorithm.scalarUTF16Unrolled16 100 avgt 2552.966 > ± 0.089 ns/op > StringHashCode.Algorithm.scalarUTF16Unrolled16 1000 avgt 25 450.912 > ± 1.834 ns/op > StringHashCode.Algorithm.scalarUTF16Unrolled161 avgt 25 4403.988 > ± 2.927 ns/op > StringHashCode.Algorithm.scalarUTF16Unrolled8 0 avgt 25 2.401 > ± 0.032 ns/op > StringHashCode.Algorithm.scalarUTF16Unrolled8 1 avgt 25 5.091 > ± 0.396 ns/op > StringHashCode.Algorithm.scalarUTF16Unrolled810 avgt 2512.801 > ± 0.189 ns/op > StringHashCode.Algorithm.scalarUTF16Unrolled8 100 avgt 2552.068 > ± 0.032 ns/op > StringHashCode.Algorithm.scalarUTF16Unrolled8 1000 avgt 25 453.270 > ± 0.340 ns/op > StringHashCode.Algorithm.scalarUTF16Unrolled8 1 avgt 25 4433.112 > ± 2.699 ns/op > > > At Datadog, we handle a great amount of text (through logs management for > example), and hashing String represents a large part of our CPU usage. It's > very unlikely that we are the only one as String.hashCode is such a core > feature of the JVM-based languages with its use in HashMap for example. > Having even only a 2x speedup would allow us to save thousands of CPU cores > per month and improve correspondingly the energy/carbon impact. > > [1] > https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision: Fix some merge conflicts - Changes: - all: https://git.openjdk.java.net/jdk/pull/7700/files - new:
Re: jpackage usage problems
Hi there. I have another case where running jpackage emits Bundler DEB Bundle failed because of java.lang.NullPointerException: Cannot invoke "java.lang.CharSequence.length()" because "this.text" is null I have never experienced NullPointerExceptions in other JDK tools. Seems to me JPackage is a new kid on the block. In this case, JPackage is invoked to finish from an existing appimage to the final package. the failure is caused because some important files are missing in appimage. The previous run is even more puzzling for me. It is supposed to create the appimage directory. And while it emits no error message, on my development machine it runs reliably while on the Github Runner it just does not create all files - no error message, no exit code - nothing. Any idea what I could be looking at? Hiran On Mon, 2022-04-04 at 08:49 +0200, Hiran Chaudhuri wrote: > Hello Alex, > > I tried running the same command with the jdk19 you pointed at. As a > first, I get this output: > > $JAVA_HOME/bin/jpackage --version > 19-ea > > With that, I invoked the command as before, and i fairly got the same > output. So the behaviour in the latest version has not changed. > > Two things I'd like to point out: > - there is no JPackage version in the output itself so both you and > me > have to trust the correct one was called > - I found out the mistake: I should have used > --app-image build/app-image/SettlersRemake > but JPackage gave a warning in the beginning and processed all the > rest > > Hiran > > > $JAVA_HOME/bin/jpackage --app-image build/app-image --verbose --dest > build > [08:41:58.675] Warning: app-image dir not generated by jpackage. > [08:41:58.688] Running dpkg > [08:41:58.696] Command [PID: 21712]: > dpkg --print-architecture > [08:41:58.696] Output: > amd64 > [08:41:58.698] Returned: 0 > > [08:41:58.702] Running dpkg > [08:41:58.719] Command [PID: 21714]: > dpkg -s coreutils > [08:41:58.719] Output: > Package: coreutils > Essential: yes > Status: install ok installed > Priority: required > Section: utils > Installed-Size: 7196 > Maintainer: Ubuntu Developers < > ubuntu-devel-disc...@lists.ubuntu.com> > Architecture: amd64 > Multi-Arch: foreign > Version: 8.30-3ubuntu2 > Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 > (>= > 2.28), libselinux1 (>= 2.1.13) > Description: GNU core utilities > This package contains the basic file, shell and text > manipulation > utilities which are expected to exist on every operating system. > . > Specifically, this package includes: > arch base64 basename cat chcon chgrp chmod chown chroot cksum > comm > cp > csplit cut date dd df dir dircolors dirname du echo env expand > expr > factor false flock fmt fold groups head hostid id install join > link ln > logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup > nproc > numfmt > od paste pathchk pinky pr printenv printf ptx pwd readlink > realpath rm > rmdir runcon sha*sum seq shred sleep sort split stat stty sum > sync > tac > tail tee test timeout touch tr true truncate tsort tty uname > unexpand > uniq unlink users vdir wc who whoami yes > Homepage: http://gnu.org/software/coreutils > Original-Maintainer: Michael Stone > [08:41:58.719] Returned: 0 > > [08:41:58.720] Running dpkg-deb > [08:41:58.722] Warning: app-image dir not generated by jpackage. > [08:41:58.723] Warning: app-image dir not generated by jpackage. > [08:41:58.723] java.lang.NullPointerException: Cannot invoke > "java.lang.CharSequence.length()" because "this.text" is null > at > java.base/java.util.regex.Matcher.getTextLength(Matcher.java:1769) > at java.base/java.util.regex.Matcher.reset(Matcher.java:415) > at java.base/java.util.regex.Matcher.(Matcher.java:252) > at > java.base/java.util.regex.Pattern.matcher(Pattern.java:1144) > at > jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$static$1(Li > nu > xDebBundler.java:84) > at > jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.validate(Linux > Pa > ckageBundler.java:72) > at > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments > .j > ava:688) > at > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Argumen > ts > .java:561) > at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) > at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) > [08:41:58.725] jdk.jpackage.internal.PackagerException: Bundler DEB > Bundle failed because of java.lang.NullPointerException: Cannot > invoke > "java.lang.CharSequence.length()" because "this.text" is null > at > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments > .j > ava:710) > at > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Argumen > ts > .java:561) > at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) >
