Re: Branchless binary search in Java?

2023-07-28 Thread Dawid Weiss
> Actually this is exactly the same for Java:
>

Yup, I know (we all know by now, I guess). People (including me) evidently
crave this low, iron-level control, while at the same time mostly try to
dodge writing any software in languages that are designed to be close to
the hardware. There is a love-hate relationship there that I often find
amusing.

D.

>


JDK 22 is in Rampdown Phase 2 | Annotation Processing Change Heads-up

2023-07-28 Thread David Delabassee
Welcome to the OpenJDK Quality Outreach summer update.

JDK 21 is now in Rampdown Phase Two [1], its overall feature has been frozen a 
few weeks ago. Per the JDK Release Process [2] we have now turned our focus to 
P1 and P2 bugs, which can be fixed with approval [3]. Late enhancements are 
still possible, with approval, but the bar is now extraordinarily high [4]. 
That also means that the JDK 21 Initial Release Candidates are fast 
approaching, i.e., August 10 [5]. So, and in addition to testing your projects 
with the latest JDK 21 early-access builds, it is now also a good time to start 
testing with the JDK 22 early-access builds.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2023-July/008034.html
[2] https://openjdk.org/jeps/3
[3] https://openjdk.org/jeps/3#Fix-Request-Process
[4] https://openjdk.org/jeps/3#Late-Enhancement-Request-Process
[5] https://openjdk.org/projects/jdk/21/


## Heads-up - JDK 21 & JDK 22: Note if implicit annotation processing is being 
used

Annotation processing by javac is enabled by default, including when no 
annotation processing configuration options are present. We are considering 
disabling implicit annotation processing by default in a future release, 
possibly as early as JDK 22 [6]. To alert javac users of this possibility, as 
of JDK 21 b29 and JDK 22 b04, javac prints a note if implicit annotation 
processing is being used [7]. The reported note is:

Annotation processing is enabled because one or more processors were
found on the class path. A future release of javac may disable
annotation processing unless at least one processor is specified by
name (-processor), or a search path is specified (--processor-path,
--processor-module-path), or annotation processing is enabled
explicitly (-proc:only, -proc:full).
Use -Xlint:-options to suppress this message.
Use -proc:none to disable annotation processing.

Good build hygiene includes explicitly configuring annotation processing. To 
ease the transition to a different default policy in the future, the 
new-in-JDK-21 `-proc:full` javac option requests the current default behavior 
of looking for annotation processors on the class path.

[6] https://bugs.openjdk.org/browse/JDK-8306819
[7] https://bugs.openjdk.org/browse/JDK-8310061


## Heads-up - JDK 22: JLine is now the Default Console Provider

In JDK 22, `System.console()` has been changed [8] to return a `Console` with 
enhanced editing features that improve the experience of programs that use the 
`Console` API. In addition, `System.console()` now returns a `Console` object 
when the standard streams are redirected or connected to a virtual terminal. 
Prior to JDK 22, `System.console()` instead returned `null` for these cases. 
This change may impact code that checks the return from `System.console()` to 
test if the JVM is connected to a terminal. If required, the 
`-Djdk.console=java.base` flag will restore the old behavior where the console 
is only returned when it is connected to a terminal. Starting JDK 22, one could 
also use the new `Console.isTerminal()` method to test if the console is 
connected to a terminal.

[8] https://bugs.openjdk.org/browse/JDK-8308591


## JDK 21 Early-Access Builds

The JDK 21 early-access builds 33 are available [9], and are provided under the 
GNU General Public License v2, with the Classpath Exception. The Release Notes 
are available here [10] and the Javadoc here [11].

[9] https://jdk.java.net/21/
[10] https://jdk.java.net/21/release-notes
[11] https://download.java.net/java/early_access/jdk21/docs/api/


## JDK 22 Early-Access Builds

The JDK 22 early-access builds 8 are available [12], and are provided under the 
GNU General Public License v2, with the Classpath Exception. The Release Notes 
are available here [13].

[12] https://openjdk.org/projects/jdk/22
[13] https://jdk.java.net/22/release-notes

### Changes in recent JDK 22 builds (b2-b8) that may be of interest:

Note that this is only a curated list of changes, make sure to check [14] for 
additional changes.

- JDK-8309882: LinkedHashMap adds an errant serializable field [Reported by 
Eclipse Collections]
- JDK-8312366: [arm32] Build crashes after JDK-8310233 [Reported by JaCoCo]
- JDK-8167252: Some of Charset.availableCharsets() does not contain itself 
[Reported by IntelliJ]
- JDK-8310061: Note if implicit annotation processing is being used
- JDK-8308591: JLine as the default Console provider
- JDK-8312019: Simplify and modernize java.util.BitSet.equals
- JDK-8308593: Add KEEPALIVE Extended Socket Options Support for Windows
- JDK-8227229: Deprecate the launcher -Xdebug/-debug flags that have not done 
anything since Java 6
- JDK-6983726: Reimplement MethodHandleProxies.asInterfaceInstance
- JDK-8281658: Add a security category to the java -XshowSettings option
- JDK-8310201: Reduce verbose locale output in -XshowSettings launcher option
- JDK-8295894: Remove SECOM certificate that is expiring in September 2023
- 

Re: Branchless binary search in Java?

2023-07-28 Thread Uwe Schindler
Actually this is exactly the same for Java: You can try whatever you 
want, the outcome of the dynamic optimization applied by various dynamic 
building blocks (Java bytecode, Java/Hotspot version, command line 
parameters, hardware CPU, virtualization) is not predictable and any 
change anywhere may produce different results. So we should stop on 
arguing about changing *our* code to improve assembly code. If we have 
some code on our side and it is not correctly converted to CMOV, we 
should open bug report on OpenJDK (Chris H. and I can do this easily - 
and ask for improvement).


As you have seen in my other answer to this thread: Hotspot applies CMOV 
depending on analysis of branches. So in general our code *should* make 
us of CMOV. You can only get certainity by using hsdis and print of 
assembly for some of our methods which you think should use CMOV. But 
there's no guarantee that it is applied. And as always: It may take a 
very long time until Hotspot replaces the standard branched code by 
conditional moves (as they have significant overhead if used in cases 
where the result is


With Hotspot you can try to add -XX:ConditionalMoveLimit ("Limit of ops 
to make speculative when using CMOVE") and try with different values (0 
disables, default is 3 on x86 and aarch64, 4 on arm). But as always: 
Wait long enough.


To enforce usage of CMOV (maybe that's the first thing for trying around 
and to look on the type of assembly created; but this may slow down 
other code as CMOV is always used, without analysis): 
-XX:+UseCMoveUnconditionally ("Generates CMove (scalar and vector) 
instructions regardless of profitability analysis.")


Uwe

P.S.: Hotspot also has cmov for vectorized code

Am 28.07.2023 um 09:08 schrieb Dawid Weiss:


Specifically, one of the fascinating Tantivy optimizations is the
branchless binary search:
https://quickwit.io/blog/search-a-sorted-block.


This is an interesting post, thanks for sharing, Mike. I remember when 
people did such low-level tricks frequently (but on much simpler 
processors and fairly consistent hardware) and it
always makes me wonder whether all the moving blocks involved here 
(rust, llvm, actual hardware) make it sane - any change in any of 
these layers may affect the outcome (and debugging what 
actually happened will be a nightmare...). I like it though - nice 
intellectual exercise and some assembly dumps for a change. ;)


D.


--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:u...@thetaphi.de


Re: Branchless binary search in Java?

2023-07-28 Thread Dawid Weiss
> Specifically, one of the fascinating Tantivy optimizations is the
> branchless binary search: https://quickwit.io/blog/search-a-sorted-block.
>

This is an interesting post, thanks for sharing, Mike. I remember when
people did such low-level tricks frequently (but on much simpler processors
and fairly consistent hardware) and it
always makes me wonder whether all the moving blocks involved here (rust,
llvm, actual hardware) make it sane - any change in any of these layers may
affect the outcome (and debugging what actually happened will be a
nightmare...). I like it though - nice intellectual exercise and some
assembly dumps for a change. ;)

D.

>