JanecekPetr | 1 year ago | on: JEP draft: Prepare to make final mean final
JanecekPetr's comments
JanecekPetr | 1 year ago | on: JEP draft: Prepare to make final mean final
https://github.com/Randgalt/record-builder
The upsides are: - it generates code and does not do anything funky with internals, - it has a lot of knobs if you need something a little different.
The downside is that it does not provide you with the other Lombok annotations. In practice that has been OK!
JanecekPetr | 1 year ago | on: Analyzing the codebase of Caffeine, a high performance caching library
That's kind of the idea of Caffeine, it has admission buffers, and it adapts automatically between LRU and LFU. The original algorithm is called Windiw TinyLFU (design https://github.com/ben-manes/caffeine/wiki/Design), see it in action e.g. here: https://github.com/ben-manes/caffeine/wiki/Efficiency
JanecekPetr | 2 years ago | on: JEP Draft: Integrity and Strong Encapsulation
> "will not work with no recourse"
No, the CLI `--add-opens` CLI option will stay. In other words, applications will need to consciously enable the encapsulation-breaking stuff. Is that bad? Modern software moved to public APIs quite a bit ago. That said, if old applications want to use new JDKs, they will require quite some developement, yes.
JanecekPetr | 3 years ago | on: Java 20: A Sneak Peek on the Panama FFM API
I take issue with the thing being a part of HexFormat. It should use hexformat, optionally. What if I want to dump the memory to binary or octal instead? The hexformat class itself could have been an adjustable BaseNFormatter :(.
Sorry for the tangent, it had to get out somewhere and I did not think it was worthy of an email in the actual review thread : - )
JanecekPetr | 3 years ago | on: JEP draft: 64 bit object headers
Not Caffeine, that's the caching library. You probably meant one of FastUtil, Eclipse Collections, Koloboke, HPPC(-RT), they all provide primitive specializations of Maps and Collections.
For off-heap maps, now that's more interesting! I know about Chronicle Map, MapDB, https://github.com/snazy/ohc and https://github.com/RuedigerMoeller/fast-serialization/wiki/O....
JanecekPetr | 4 years ago | on: SQL: The difference between WHERE and HAVING
For me the aha moment was to understand the logical order of SQL operations: https://blog.jooq.org/a-beginners-guide-to-the-true-order-of.... Never had a problem since.
JanecekPetr | 4 years ago | on: Log4j RCE Found
Interestingly, no, the tag doesn't have to be in the formatting string. See https://news.ycombinator.com/item?id=29507511.
JanecekPetr | 4 years ago | on: Log4j RCE Found
No, this is about log4j2 which is kinda new (2.0.0 was released 2014). Otherwise, yeah, this is terrible, especially since the tag doesn't even have to be in the formatting string.
JanecekPetr | 4 years ago | on: GC progress from JDK 8 to JDK 17
For native binaries, we now have https://www.graalvm.org/reference-manual/native-image/, but it probably doesn't yet work nicely with game frameworks? Not sure.
There are some engines, frameworks: https://jmonkeyengine.org/, https://litiengine.com/, https://libgdx.com/, https://www.lwjgl.org/.
But I have no real experience with any of those.
JanecekPetr | 4 years ago | on: GC progress from JDK 8 to JDK 17
...and they're missing out, that's exactly the message. By the way, I'd be shocked if Java 8 was still more than half of the running server-side JVMs. There's a lot of them for sure, but I'd be willing to bet it's gonna be less than a half now, and declining.
JanecekPetr | 4 years ago | on: A Tale of Java Hash Tables
It's simply a completely different implementation. Some of the optimiization passes are the same, obviously, but overall it simply performs ... differently.
JanecekPetr | 4 years ago | on: A Tale of Java Hash Tables
Correct! Inlining obviously costs CPU, code cache space, and makes the receiver method bigger so that it's less likely it will be inlined itself. If there ever is a decompilation occuring, the inlining efforts were pretty much wasted.
JanecekPetr | 4 years ago | on: A Tale of Java Hash Tables
Nice. Thanks. (For other viewers, all the non-standard maps I'm aware of are trying to avoid allocating those pesky Map.Entry objects, that's why they generally take up much less memory.)
JanecekPetr | 4 years ago | on: A Tale of Java Hash Tables
That's because they used primitives, no? In that case also look at some other options: https://www.reddit.com/r/java/comments/r0b9o9/a_tale_of_java.... While I still think Koloboke in general is the fastest, I do agree that the difference between it and fastutil will not be very big.
Or was this for Object/boxed primitives, too?
JanecekPetr | 4 years ago | on: A Tale of Java Hash Tables
Indeed, max bytecode count (FreqInlineSize and MaxInlineSize) and inlining depth (MaxInlineLevel). Your GC choice will also slightly modify the inlining decisions, and then obviously GraalVM will be completely different.
JanecekPetr | 4 years ago | on: A Tale of Java Hash Tables
> i couldn't even inline my functions
You could, manually :). Either way if they're hot, they're inlined.
One common trick for open-addressing maps in Java I don't see in your implementations is to have an array of keys zipped with values (or two arrays, one for keys, one for values) instead of array of Entries. This improves locality and indirection a bit. Obviously more is needed for even more speed.
(Mandatory "in the future it will be better": Valhalla is coming in a few years, that's when we'll have much more control over the memory layout.)
JanecekPetr | 4 years ago | on: Shenandoah in OpenJDK 17: Sub-millisecond GC pauses
If it's not behind XX:+UnlockExperimentalVMOptions (or a preview/incubator module), it's considered stable and prod-ready, yes. Will there be fixes and improvements? Yes. Should you be afraid to use it for business? No, but obviously test it first.
JanecekPetr | 4 years ago | on: Stockfish 14
No, they use 12 on all of my devices. Maybe update your browser or something?
JanecekPetr | 4 years ago | on: Obvious and possible software innovations
Automated ffi parser soon (TM) to be in standard Java: https://github.com/openjdk/panama-foreign/blob/foreign-jextr...
page 1
Other tools and libraries generally do not interact in such an errorprone manner.
That said, when you know how it works, what it needs, and you know how to iron all of those tiny wrinkles, it works fine and saves you some code and/or sanity. It's not the devil, it's a powerful tool with some downsides.