<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Jiří Holuša on foojay.io - Friends of OpenJDK</title><link>https://foojayio.github.io/website/today/author/jiri-holusa/</link><description>Articles written by Jiří Holuša on foojay.io - Friends of OpenJDK</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 17 Jul 2026 08:02:07 +0000</lastBuildDate><atom:link href="https://foojayio.github.io/website/today/author/jiri-holusa/index.xml" rel="self" type="application/rss+xml"/><item><title>Warm Up Fast, Run Lean: Vertical Scaling for Java on Kubernetes with Azul Prime and Kedify</title><link>https://foojayio.github.io/website/today/warm-up-fast-run-lean-vertical-scaling-for-java-on-kubernetes-with-azul-prime-and-kedify/</link><pubDate>Fri, 17 Jul 2026 08:02:07 +0000</pubDate><guid>https://foojayio.github.io/website/today/warm-up-fast-run-lean-vertical-scaling-for-java-on-kubernetes-with-azul-prime-and-kedify/</guid><description>&lt;p&gt;Autoscaling on Kubernetes has evolved significantly, but many production systems still rely on reactive scaling based on CPU and memory utilization. The issue is that resource metrics often lag behind real demand. By the time the CPU rises, users may already be experiencing unacceptable latency.&lt;/p&gt;
&lt;p&gt;For most real services, horizontal scaling should be driven by proactive workload signals such as request rate, concurrency, or queue depth, rather than raw CPU alone. To learn more about this, see &lt;a href="https://kedify.io/resources/blog/autoscaling-delay-resource-based-hpa-vs-proactive-metrics" target="_blank" rel="noopener noreferrer"&gt;this post&lt;/a&gt;
 on autoscaling delay and proactive metrics.&lt;/p&gt;</description></item><item><title>JetBrains and Azul Collaborate on Kotlin Performance in Various JVMs</title><link>https://foojayio.github.io/website/today/jetbrains-and-azul-collaborate-on-kotlin-performance-in-various-jvms/</link><pubDate>Wed, 10 Sep 2025 07:11:44 +0000</pubDate><guid>https://foojayio.github.io/website/today/jetbrains-and-azul-collaborate-on-kotlin-performance-in-various-jvms/</guid><description>&lt;p&gt;&lt;em&gt;&lt;strong&gt;JetBrains and Azul are collaborating on a shared vision of running Kotlin-generated bytecode on a high-performance &lt;a href="https://www.azul.com/" target="_blank" rel="noopener noreferrer"&gt;Java platform&lt;/a&gt;
 to find new ways to enhance runtime performance. Benchmarks of Kotlin performance on Azul Platform Prime have yielded some eye-opening results.&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&lt;strong&gt;In this article you will learn:&lt;/strong&gt;&lt;/em&gt;&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;em&gt;&lt;strong&gt;Kotlin is a high-level programming language designed to interoperate fully with the JVM&lt;/strong&gt;&lt;/em&gt;&lt;/li&gt;
&lt;li&gt;&lt;em&gt;&lt;strong&gt;Runtime performance and scalability are derived predominantly from the JVM&lt;/strong&gt;&lt;/em&gt;&lt;/li&gt;
&lt;li&gt;&lt;em&gt;&lt;strong&gt;JetBrains and Azul benchmarked Kotlin on both standard OpenJDK and on Azul Platform Prime, a high-performance &lt;a href="https://www.azul.com/" target="_blank" rel="noopener noreferrer"&gt;Java platform&lt;/a&gt;
&lt;/strong&gt;&lt;/em&gt;&lt;/li&gt;
&lt;li&gt;&lt;em&gt;&lt;strong&gt;Platform Prime reduced latencies by 23.9% and improved throughput by as much as 30.5%&lt;/strong&gt;&lt;/em&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;As modern JVMs combine language features and runtime optimizations, they unlock new levels of performance.&lt;/p&gt;</description></item><item><title>Controlling JIT Compiler Overhead to Avoid CPU Autoscaling</title><link>https://foojayio.github.io/website/today/controlling-jit-compiler-overhead-to-avoid-cpu-autoscaling/</link><pubDate>Wed, 01 Nov 2023 07:54:33 +0000</pubDate><guid>https://foojayio.github.io/website/today/controlling-jit-compiler-overhead-to-avoid-cpu-autoscaling/</guid><description>&lt;p&gt;&lt;strong&gt;Today&amp;rsquo;s modern, containerized, elastically scaling Java clusters often rely on CPU utilization as the main trigger for scaling out new instances. Imperfect as this metric may be, it is ubiquitous to scale out new instances based on CPU utilization going over some limit. Often that limit is surprisingly low, somewhere around 40 to 50%.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;a href="https://www.azul.com/products/prime/" target="_blank" rel="noopener noreferrer"&gt;Azul Platform Prime&lt;/a&gt;
 replaces OpenJDK&amp;rsquo;s HotSpot C2 compiler with the Falcon JIT compiler. &lt;a href="https://docs.azul.com/prime/Falcon-Compiler" target="_blank" rel="noopener noreferrer"&gt;Falcon&lt;/a&gt;
 generates much faster code than OpenJDK, allowing you to handle more transactions in a container before hitting your CPU utilization limit. And, Prime&amp;rsquo;s smoother and more consistent execution allows you to safely raise your CPU utilization to 60-70%, resulting in massive gains in carrying capacity for each container and lower overall cloud costs to handle your total Java workload.&lt;/p&gt;</description></item></channel></rss>