You mean expedite whole chunks of logic to a different language, then make your build process much more complicated by having to maintain a completely new ecosystem and compiler infrastructure and make testing more cumbersome?

Sorry, but this is just a bad advice.

I was annoyed when the announced 1st gen Ryzen isn't supported in Windows 11.

~15 years ago, the last time I used Oracle in production, that was still standard practice. I'd be interested to hear from someone who's used it recently.

File system semantics need a rethink. Here's what I've proposed. This is not original with me; these are all things implemented in some non-UNIX-based systems.

Files should come in several kinds:

- Unit files. They're immutable, but replaceable. This is the normal case. You create them with "creat", write them, and when closed, they replace any previous version with the same name. Any program which opens one for reading sees a complete file. On a crash before close, the new file is dropped and the old version remains. If a program aborts, that also happens. An explicit close commits the file update.

- Log files. These are append only. On a crash, you are guaranteed that the file will be intact to some point ending at a write boundary. The last transactions may be lost, but the file must not tail off into junk. For journals, log files, etc.

- Temp files. These disappear on a crash.

- Managed files. These are for databases. They can do everything files can do.

Along with this, you need async I/O. This is primarily for log files and managed files. When you do a write, you get two callbacks, one when the buffer has been copied, and one when the data has been committed to permanent storage and will survive a crash. It is the job of the OS, drivers, and devices to not send the data-committed completion until the data is safe. Only a few programs need that, but they're the important ones - database managers.

This turns the fsync problem around. Instead of doing an fsync to force write-out, databases wait for a completion before considering the data committed. It's not a flush-everything; it's a commit-complete for a single write. So if you have multiple I/O operations pending on a single file, a normal event in database land, there's no big stall for a cache flush.

There's also no incentive for drive manufacturers to send commit-completes early. The only people who use them are the ones who will notice if someone cheats. Most bulk I/O is on unit files, where something is being copied.

(There are mainframe systems that had this sort of thing half a century ago.)

How does a massive company like Intel who's work heavily involves code/compiler optimization not profile their drivers for something this simple?

I do not believe so. The "affected list" which includes 11 is for the complete set of the "CPU" - Critical Patch Update.

This specific one was introduced with the rewriting of these parts of the code from C++ to Java, and that happened with Java 15.

For folks on RHEL, the java-17-openjdk package for RHEL 8 has been updated: https://access.redhat.com/errata/RHSA-2022:1445.

> The official OpenJDK project lists the planned release date of 17.0.3 as April 19th, still the latest available GA release is 17.0.2

> (https://wiki.openjdk.java.net/display/JDKUpdates/JDK+17u).

I don't think there 17.0.3 ever will be available from openjdk.java.net; there's no LTS for upstream builds, and since Java 18 is out already, no further builds of 17 should be expected there. IMO, this warrants some clarification on that site though.

Not that a lot of companies are using the Java 15+. People generally stick to 8 or 11.