标签：#jvm

JEP 401, integrated into JDK 28, introduces value objects. These new class instances feature final fields, altered behavior for equality checks, and stricter construction and synchronization rules. It aims to enhance efficiency and reduce memory allocation costs. However, the preview is disabled by default and requires specific configuration at compile and run time. By A N M Bazlur Rahman

Andrea Peruffo discusses the evolution of WebAssembly beyond the browser and its growing role on the server-side JVM. He covers performance advancements in Wasm runtimes, moving from interpreters to efficient JIT compilation, and explores real-world production use cases ranging from edge computing platforms to modular plugin architectures. By Andrea Peruffo

Quando eu decidi aprender como a JVM funciona por dentro, eu precisava de uma linguagem simples o suficiente pra não atrapalhar o aprendizado. Algo onde eu pudesse focar na mecânica do compilador sem me perder na complexidade da linguagem fonte. Brainfuck foi a escolha óbvia. Esse é o primeiro post de uma série de três onde a gente vai construir, do zero, um compilador que transforma código Brainfuck em bytecode JVM executável. Sem dependências externas, sem framework, só Node.js puro. No final da série, você vai ter um compilador que gera arquivos .class válidos que rodam direto no java . O código completo está no GitHub . Nesse primeiro post, a gente vai construir o interpretador - que é a base pra tudo que vem depois. O que é Brainfuck Brainfuck é uma linguagem de programação esotérica criada em 1993 por Urban Müller. Ela tem 8 comandos . Oito. E ainda assim é Turing-completa - ou seja, em teoria, você pode computar qualquer coisa que qualquer outra linguagem computa. O modelo de execução é simples: Uma fita de memória com 30.000 células, cada uma armazenando um byte (0-255) Um ponteiro que aponta pra célula atual Entrada e saída (stdin/stdout) Os 8 comandos: Comando O que faz + Incrementa o valor da célula atual - Decrementa o valor da célula atual > Move o ponteiro uma célula pra direita < Move o ponteiro uma célula pra esquerda . Imprime o valor da célula atual como caractere ASCII , Lê um byte da entrada e armazena na célula atual [ Se a célula atual é zero, pula pro ] correspondente ] Se a célula atual não é zero, volta pro [ correspondente Qualquer outro caractere é ignorado - o que significa que você pode escrever comentários livremente no meio do código. Um exemplo simples Pra imprimir a letra "A" (código ASCII 65), você precisa colocar o valor 65 na célula e usar . : +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ . São 65 sinais de + seguidos de um . . Funciona, mas é feio. Uma forma mais elegante: ++++++++ [ > ++++++++ < - ] > +. O qu

Every Java engineer who has connected JConsole — or JDK Mission Control — to a server in another network segment knows the ritual. Open the JMX port. Discover that RMI quietly opened a second port — random by default. Pin it with a system property nobody remembers without searching. File a firewall ticket for both. Wait. What fewer people know: the JMX specification shipped with the second remote transport that has none of these problems. One socket, one port, TLS underneath if you want it. It's called JMXMP — the JMX Messaging Protocol. It lost for the least mysterious reason in software — RMI shipped by default, JMXMP was a separate download, and defaults win — and its reference implementation has been effectively abandoned since around 2008. Yet, it never quite died. Code that refuses to die usually knows something. I didn't set out to resurrect it. I fell into it. The port dance, briefly The default remote JMX stack rides on RMI. The connection URL tells you most of the story: service:jmx:rmi:///jndi/rmi://host:1099/jmxrmi I'll spare you the full anatomy behind that URL — there's a JNDI lookup in it, and that second, dynamically assigned port from the ritual above; few people ever learn the details, which is rather the point. Dynamic ports were a reasonable design for 1999's flat networks. Between today's firewalls, NAT, and containers, they're friction — not because RMI is bad, but because the network it was designed for no longer exists. The JMXMP URL: service:jmx:jmxmp://host:9875 One socket. TCP in, TCP out. That's the whole networking story. How I ended up in this codebase I maintain JConsoleBooster , a modernized JConsole. It shipped fine for years on the 2008-era JMXMP jar — the one historically distributed as jmxremote_optional / jmx-optional , out of Sun's OpenDMK project, republished over the years by several parties because people kept needing single-socket JMX. Then I moved the app to a jlink -built runtime. An automatic module from 2008 does not coo

The incident that taught me to respect pinning looked like nothing. A service freshly migrated to virtual threads, a load test that plateaued at about 420 requests per second no matter how much traffic we threw at it, CPU sitting at 9%, zero errors, zero warnings, nothing in the logs. The machine had 8 cores, and the one downstream HTTP call in the hot path took about 19 ms. Do the arithmetic: 8 × (1000 / 19) ≈ 421. The service that was supposed to scale to millions of virtual threads was serving exactly one request per CPU core. Loom had quietly handed us back a bounded thread pool, and the code looked perfectly innocent. That failure mode has a name — pinning — and this is the field guide I wish I'd had that night: what it is, the two (and only two) things that cause it, what JDK 24 changed, and how to catch it before your throughput graph does. What pinning actually is A virtual thread doesn't own an OS thread. It runs on a small pool of platform threads called carrier threads — concretely, the workers of a dedicated ForkJoinPool living in a thread group named CarrierThreads , with default parallelism equal to Runtime.availableProcessors() . When a virtual thread blocks — on I/O, a lock, a queue — it normally unmounts : it saves its stack, steps off the carrier, and frees that carrier to run another virtual thread. That unmount is the entire trick that lets a handful of OS threads serve millions of virtual ones. Pinning is when the unmount can't happen. The virtual thread blocks but stays mounted, and its carrier sits there doing nothing useful for the whole duration. One pinned carrier is a rounding error. But the default carrier pool is only as big as your core count, so if a hot path pins routinely, you pin every carrier at once — and then no virtual thread anywhere makes progress. That's not a slowdown; it's scheduler starvation, and from the outside it looks a lot like a deadlock. You can raise the ceiling with -Djdk.virtualThreadScheduler.parallelism=N , bu

Block, Inc. describes migrating ~450 JVM repositories into a monorepo across Cash App and Square engineering to reduce dependency drift and coordination overhead. The system supports ~8,800 weekly builds with ~10 min p90 CI time. The approach improves cross-service changes, build visibility, and developer experience through dependency graph–based builds, selective CI, and custom IDE tooling. By Leela Kumili