BinaryRage's comments

You can relax permissions while avoiding the flag with BashTool sandboxing, see /sandbox.

No, these are just default imports. Module import declarations are in for JDK 25 to make this kind of thing even easier: https://openjdk.org/jeps/511

See Brian's article "Paving the on-ramp": https://openjdk.org/projects/amber/design-notes/on-ramp

I remember talking to Brendan about the PreserveFramePointer patch during my first months at Netflix in 2015. As of JDK 21, unfortunately it is no longer a general purpose solution for the JVM, because it prevents a fast path being taken for stack thawing for virtual threads: https://github.com/openjdk/jdk/blob/d32ce65781c1d7815a69ceac...

The figure is about the overall improvement, not sure why that reads increase.

On JDK 8 we are using G1 for our modern application stack, and we saw a reduction in CPU utilisation with the upgrade with few exceptions (saw what I believe is our first regression today: a busy wait in ForkJoinPool with parallel streams; fixed in 19 and later it seems).

G1 has seen the greatest improvement from 8 to 17 compared to its counterparts, and you also see reduced allocation rates due to compact strings (20-30%), so that reduces GC total time.

It's a virtuous cycle for the GRPC services doing the heavy lifting: reduced pauses means reduced tail latencies, fewer server cancellations and client hedging and retries. So improvements to application throughput reduce RPS, and further reduce required capacity over and above the CPU utilisation reduction due to efficiency improvements.

JDK 21 is a much more modest improvement upgrading from 17, perhaps 3%. Virtual threads are incredibly impressive work, and despite having an already highly asynchronous/non-blocking stack, expect to see many benefits. Generational ZGC is fantastic, but losing compressed oops (it requires 64-bit pointers) is about a 20% memory penalty. Haven't yet done a head to head with Genshen. We already have some JDK 21 in production, including a very large DGS service.

Lunatics all.

Same for SimCity 2013, except the flaws extended to every agent. I've always thought that's why they limited the city size so heavily. Such a shame, because there was so much promise there.

Power, water, etc. randomly chose a direction at a junction, so even basic grid would make it impossible to power a building on the other side of the city, even if the power demand was there https://www.youtube.com/watch?v=tvq6zAMJfOU.

Traffic and pedestrians were attracted to available houses/work, but randomly every day, rather than having a defined home/work location. I built a pedestrian heavy city and would watch crowds of pedestrians head for the nearest available house on a street, before the whole street filled, and they turned around for the next nearest. Same for work, shopping, despite there being plenty available.

log4j2 supports lookups, which allows you to add additional logging context:

https://logging.apache.org/log4j/2.x/manual/lookups.html

The problem here is the JNDI lookup because for historical reasons there is code in these providers which causes Java to deserialize and load bytecode if it's found in a result for a lookup against an LDAP server. That exploit was partially fixed in the JDK in 2008, then in 2018, but there are multiple naming providers that are affected.

Yes, it's enabled by default before 2.15.0, released today to mitigate this issue.

I was staggered by how much adjustment was required when watching CuriousMarc's excellent Model 19 restoration series, seems incredibly finicky.

https://www.youtube.com/watch?v=_NuvwndwYSY&list=PL-_93BVApb...

They should rewrite in Rust...

You might want to link to the OSS site too - https://netflix.github.io/