Forem: Abhi

[Boost]

Abhi — Sun, 05 Apr 2026 07:20:42 +0000

Reverse engineering

Abhi — Fri, 16 Jan 2026 13:17:05 +0000

I Got Tired of Guessing JVM Performance — So I Built a Java Agent From Scratch 🚀

Abhi — Wed, 17 Dec 2025 18:29:23 +0000

Hey I am Abhishek Mule, I used to do what most backend developers do. When a Spring Boot app felt slow, I’d:

😵‍💫 Stare at logs until my eyes blurred.
⏱️ Add manual System.currentTimeMillis() timers everywhere.
☁️ Blame the database (it's always the DB, right?).
🙏 And just hope the JVM was behaving.

Deep down, I knew the truth: I didn’t actually know what the JVM was doing.

Instead of reading another "Top 10 Performance Tips" blog, I decided to do something uncomfortable. I built a JVM agent from scratch. This is the journey of vtracer.

The Starting Point: Brutal Silence 🧩

Before this, terms like Instrumentation API and Bytecode transformation were just abstract concepts. When I started, I expected clear error messages. I was wrong.

At one point, the JVM simply refused to load my agent. No errors. No stack traces. Just silence. That was Lesson #1: The JVM doesn’t owe you an explanation. If you mess up your bytecode transformer or a manifest entry, the JVM doesn't crash—it just ignores you and moves on. It’s a humbling experience to realize you're invisible to the very system you're trying to track.

The 6-Day Build Journey 🛠️

Day 1: Breaking the Seal

My only goal: Can I make the JVM acknowledge I exist? I wrote a premain method and finally saw a log line appear inside a target JVM. It felt like cracking open a sealed black box. I finally had an Instrumentation handle.

Day 2: The "Explosion" of Reality 💥

I used ByteBuddy to intercept method entry and exit.

Immediately, lesson #2 hit: Tracing everything is a disaster. My console became unusable—thousands of lines per second, a blur of text. The app was technically "working," but it was completely unobservable.

The Takeaway: Real JVM tooling is about restraint, not power. If you can't filter the noise, you're just adding to the chaos.

Day 3: Attaching to Raw Metal (No Restarts) 💉

Using the Attach API, I built a tool to find a running JVM by PID and inject the agent at runtime. No restart. No redeploy.

When I attached it to a live Spring Boot app and saw Tomcat internals like Http11Processor.recycle() executing in real-time, it hit me: This is the exact same mechanism used by million-dollar APMs—just without the marketing and the shiny UI. I was finally touching the raw metal of the ecosystem.

Day 4: Virtual Threads Aren't Magic 🪄

Java 21's Virtual Threads have massive potential, but they also have massive footguns. I wired a JFR RecordingStream to listen for jdk.VirtualThreadPinned events.

I wrote intentionally bad code (a synchronized block inside a virtual thread), and the agent caught it instantly. Virtual threads don’t fix bad blocking—they expose it.

Day 5: The Art of Sampling 📉

Tracing 100% of calls is irresponsible. I implemented Sampling (10% rate). This forced me to think like a systems engineer: predictable overhead, controlled allocations, and finding the "useful signal" in a sea of data.

Day 6: Structured Reporting

I added a Shutdown Hook and JSON output. Now, the agent leaves behind a structured report you can actually analyze, rather than a wall of text you have to scroll past.

What vtracer is Today 📍

✅ Runtime Attachment: No restarts required.
✅ Dynamic Instrumentation: Power of ByteBuddy.
✅ Smart Sampling: Minimal overhead (~2%).
✅ JFR Integration: Detecting Virtual Thread pinning.
✅ Structured JSON: Professional report generation.

What vtracer will NEVER be:

I’m not building a UI-heavy dashboard or an "AI-powered oracle." vtracer exists to understand the JVM, not to hide it.

Why This Project Matters 💡

This project didn't just teach me APIs. It taught me how fragile instrumentation can be and how much is happening below the application code that we take for granted.

The Reality Check:

If you’ve never attached to a live JVM, you don’t really know Java—you know frameworks.

Building this agent permanently changed how I debug, how I read stack traces, and how I think about performance. This project didn’t necessarily make me a "faster" developer.

It made me more honest about what I don’t know.

🔗 The Code

If you want to stop guessing and start observing, check the source:

👉 GitHub: abhishek-mule/vtracer

Java Version: 21+
Status: Early, experimental, and very real.

Learning the JVM, one uncomfortable problem at a time. ☕

Building vtracer: Day 1 – My First Java Agent Adventure with Java 21

Abhi — Tue, 16 Dec 2025 17:11:12 +0000

Hey Dev.to community! 👋

I'm Abhishek, a Java enthusiast diving deep into the JVM internals. I'm building vtracer – a low-overhead JVM agent for runtime tracing and virtual thread pinning detection.

This is Day 1 of my journey. Today, I built the foundation: a simple Java agent that loads and prints a message.

Let's dive in!

Why Java Agents? The Magic Behind the JVM

Java agents are powerful tools that let you instrument code at runtime using the Instrumentation API. They can modify bytecode, add logging, monitor performance, or even implement AOP – all without changing the original code.

Agents load in two ways:

Static: -javaagent at startup
Dynamic: Attach to running JVM

Today, we focused on static attach – the basics.

Step-by-Step: My First Premain Agent

Maven Project Setup

Created a simple Maven project with Java 21.
pom.xml with Agent Manifest

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <configuration>
                <archive>
                    <manifestEntries>
                        <Premain-Class>com.example.vtracer.Agent</Premain-Class>
                        <Can-Redefine-Classes>true</Can-Redefine-Classes>
                        <Can-Retransform-Classes>true</Can-Retransform-Classes>
                    </manifestEntries>
                </archive>
            </configuration>
        </plugin>
    </plugins>
</build>

Agent Class

package com.example.vtracer;

import java.lang.instrument.Instrumentation;

public class Agent {
    public static void premain(String agentArgs, Instrumentation inst) {
        System.out.println("[vtracer] Agent loaded successfully via premain");
        System.out.println("[vtracer] Instrumentation: " + inst);
        System.out.println("[vtracer] Ready for instrumentation – Day 1 complete!");
    }
}

Build & Run

mvn clean package
java -javaagent:target/vtracer-1.0.jar TestApp

Output:

[vtracer] Agent loaded successfully via premain
[vtracer] Instrumentation instance: sun.instrument.InstrumentationImpl@...
[vtracer] Ready for instrumentation – Day 1 complete!
Test app running...
Test app finished

What I Learned Today

premain runs before main
Manifest entries are mandatory
Instrumentation object gives power to transform classes

This is just the beginning – next, ByteBuddy for method timing!

What's Next?

Day 2: Method entry/exit timing with ByteBuddy.

Follow my journey on GitHub: https://github.com/abhishek-mule/vtracer

Star ⭐ if you're excited about JVM internals!

java #jvm #java21 #agents #bytecode

Thanks for reading! Let's build cool stuff together. 🚀

— Abhishek Mule

(Comment below if you're building something similar!)

I Was Tired of Manual Video Editing — So I Built OmniVid Lite

Abhi — Fri, 28 Nov 2025 09:33:10 +0000

****🚀 OmniVid Lite — Text-to-Video, Without the Complexity

Video creation is painful.

You open CapCut or Premiere…
drag timelines… adjust timing… export… fix something… export again.

It feels outdated — especially when LLMs can already generate text, code, and images from a single prompt.

So I built OmniVid Lite — a lightweight, fast, developer-friendly way to generate simple AI-powered videos using nothing but text instructions.

🎯 The Goal

Not another "all-in-one AI video editor."

Just a clean minimal workflow:

Text prompt ➝ API ➝ Video

No GPU-heavy diffusion models.

Instead, OmniVid Lite focuses on:

05–30 sec explanatory videos

Subtitles + narration

Basic scene transitions

Simple assets (text, shapes, images)

Think:
"Explain Kubernetes in 20 seconds" → Auto-generated animation.

🛠️ Tech Stack

Backend: FastAPI

Frontend: React

Video Rendering: Python + Manim (for animation logic)

Model: LLM (prompt → animation config)

Auth: API key based

I wanted a system that a normal developer can deploy, extend, and hack — without depending on closed SaaS APIs.

🧩 Core Architecture

User Prompt
↓
LLM Prompt Parser (Python)
↓
Scene Config (JSON)
↓
Renderer (Manim)
↓
Final .mp4 Output

The LLM doesn’t generate raw video — that would be slow and unstable.

Instead, it generates a structured scene description, like:

{
"duration": 8,
"scenes": [
{
"type": "text",
"content": "What is Blockchain?",
"animation": "fade_in"
}
]
}

This config is deterministic and editable.

That makes OmniVid Lite programmable and predictable, unlike "random AI video generators."

🧪 Example Prompt

Create a 10-second explanatory video about how DNS works.
Use subtitles, simple animations, and show request flow visually.

Output:
A short animated video showing:

browser → DNS resolver → name server → IP response.

No manual editing. No timeline.

📦 Current Features

Text-to-video via /api/v1/render

Simple Manim-based animations

Subtitles

React UI with prompt builder

API key auth

Async background rendering

🧭 What’s Next?

Voice-over generation

Image → animated explainer

Template library

Drag-and-drop scene editor

Blender-based advanced export mode

Not promising hype — just building.

🔗 Repo

https://github.com/Abhishek-mule/omnivid-lite.git

💡 Final Thought

AI won’t replace video editors.

But tools like OmniVid Lite will replace repetitive, low-creativity editing — so humans can focus on storytelling, not timeline scrubbing.

If you build videos, teach online, or work on developer tooling — there’s a lot to explore here.