DEV Community: Vishalendu Pandey

Sample EU AI Act checklist

Vishalendu Pandey — Sun, 14 Sep 2025 06:57:56 +0000

AI Risk & Governance Checklist

1. Risk Identification & Classification

[ ] Determine if the AI falls under unacceptable, high, limited, or minimal risk categories
[ ] Check if it qualifies as general-purpose AI (GPAI) or an agentic system with autonomy
[ ] Map jurisdictional scope (EU AI Act, GDPR, national laws, global markets)

2. Governance & Accountability

[ ] Assign a clear accountable owner for AI compliance
[ ] Establish an AI governance framework (policies, committees, escalation paths)
[ ] Define roles for provider, deployer, distributor, importer as per EU AI Act

3. Data Management & Quality

[ ] Ensure datasets are representative, relevant, and documented
[ ] Conduct bias and fairness audits during data prep
[ ] Apply data protection by design (minimization, anonymization, lawful basis)

4. Design & Development

[ ] Perform risk assessments at each development stage
[ ] Document model design, training, and limitations
[ ] Implement security by design (adversarial robustness, penetration testing)

5. Transparency & Documentation

[ ] Maintain technical documentation (model cards, data sheets, intended use)
[ ] Provide instructions for use to downstream deployers
[ ] Clearly state capabilities, limitations, and error rates to users
[ ] Log training data sources, model changes, and decision flows

6. Human Oversight & Control

[ ] Ensure human-in-the-loop (HITL) or human-on-the-loop (HOTL) mechanisms
[ ] Provide means to override or shut down the system safely
[ ] Train users in effective oversight and decision review

7. Testing & Validation

[ ] Conduct pre-deployment testing for accuracy, robustness, safety
[ ] Simulate adversarial and misuse scenarios
[ ] Validate against compliance and ethical standards

8. Deployment & Monitoring

[ ] Keep continuous monitoring for performance, drift, anomalies
[ ] Log significant events for traceability and accountability
[ ] Collect user feedback and incident reports systematically
[ ] Establish a decommissioning process when systems are retired

9. Impact & Rights Assessment

[ ] Conduct Fundamental Rights Impact Assessment (FRIA) if risk is non-trivial
[ ] Map risks to privacy, equality, safety, freedom of expression, employment
[ ] Document mitigation strategies for identified harms

10. Regulatory Compliance

[ ] Verify obligations under EU AI Act (risk tier-based)
[ ] Ensure compliance with GDPR, cybersecurity acts, consumer protection laws
[ ] For high-risk systems, prepare conformity assessment files
[ ] Track timelines for phased compliance obligations

11. Security & Cyber-resilience

[ ] Secure model against data poisoning, adversarial inputs, model extraction
[ ] Protect infrastructure from cyber-attacks
[ ] Monitor for misuse and malicious repurposing of outputs

12. Culture & Training

[ ] Provide responsible AI training to developers, managers, deployers
[ ] Build a culture of responsibility, questioning, and escalation
[ ] Encourage reporting of ethical or compliance concerns

Comparing Performance of Java 23 GC Algos (G1GC/ZGC/Shenandoah)

Vishalendu Pandey — Sat, 21 Dec 2024 16:26:57 +0000

So this is an article in response to the following article.
https://www.unlogged.io/post/z-garbage-collector-in-java

Why I am writing this article?

The above article quite eloquently explains the ZGC+Generational and provides some basic comparisons in terms of GC events. I wondered since ZGC+Generational which is concurrent cleaning up the JVM will definitely need more CPU (processing threads) time than other GCs. It was not without experience, I have tried ZGC (non-generational) in Java 21 and it was not good to put it lightly.

So I was now wondering, should I checkout ZGC+Generational in Java 23?

Why the heck not? So here I am, after spending around 1 day in orchestrating a comparison test to be able to quantify the difference between G1GC, ZGC+Generational GC, Shenandoah GC using Java 23.

Where is the code?

I have used the code on the article provided above as base. The modified code can be found on the following git repo:
https://github.com/vishalendu/java-gc-demo

Note:It needs JDK-23, obviously 😁

The code does the following things:
Its a spring boot project with a rest interface to create objects on java heap:

For e.g. http POST call to /api/memory/load/500 will create
10MBX50 objects in the memory, they will get garbage collected soon
after.

I have added additional dependency to expose the metrics endpoint for prometheus to be scraped for metrics (CPU/GC etc).

Note: I tried to add code/dependencies to push metrics to InfluxDB, but faced some issues, so decided to go with the (pull based) Prometheus.

What is the setup like?

Machine Used: AMD Ryzen 7 5800H with 8 cores, 30G RAM
OS: Ubuntu 24.04
Docker containers were used to deploy Grafana/Prometheus.
JDK, tried:
- OpenJDK (build 23.0.1+11-39)
- Amazon Corretto OpenJDK (build 23.0.1+8-FR)

Note: Unfortunately Shenandoah refused to run with OpenJDK build 23.0.1+11-39, so had to repeat the whole experiment with the Amazon Corretto build 23.0.1+8-FR

Where can you find all the stuff?

JDK: You can google it! and download (depending on your platform!!)

Rest of the component, scripts, docker-compose etc. can be found on this repo:
https://github.com/vishalendu/java-gc-demo-supplement

README on the repo is self-explanatory, I assume you can run docker-compose and edit basic shell scripts before running. 😉

Results, finally !! 😍

TLDR: ZGC+Generational is in a league of its own.

Process CPU (P95)

Process CPU P95 is the least in ZGC+G

.
System CPU (P95)

System CPU P95 is the least in ZGC+G

.
Pause Time (ms)

Pause Time is the least in ZGC+G, which leads to better throughput, which also shows that ZGC+G does most of the collection concurrently without stopping JVM

.
GC Overhead

GC Overhead is the least in ZGC+G, which leads to better throughput

.
GC Concurrent Time

GC Concurrent Time is the highest in ZGC+G which shows that ZGC+G does most of the collection concurrently without stopping JVM

Note:

You can checkout the values for all the test in the supplement repo provided in the excel sheet results-comparison.xlsx

You can also checkout screenshots of the grafana dashboards for all the tests on the supplement git repo

Phew WOW!!

The ZGC+Generation GC Type in Java 23 looks revolutionary, I had my doubts, since its continuously and concurrently cleaning the heap, I was expecting more CPU Utilization. But I was completely amazed at the low CPU Utilization and the low (abismal) GC Overheads in the ZGC. Cannot wait to try it out in an actual application !!!

Shenandoah, personally I have not used it but it fared better than G1GC. Coming in the second place.

G1GC, it feels like the GC overheads and the high CPU utilization have costed G1GC dearly, its the worst performing of the three. Never thought I would be saying this but I did not expect this vast difference in performance.

Thanks

Please let me know what you feel about this article, anything more or anyother metrics that could be added to the comparison. 😎

Using Java EpsilonGC to look at memory allocation.

Vishalendu Pandey — Sat, 07 Sep 2024 06:16:24 +0000

The code referenced in this article is sourced from sample code available on the Oracle blog regarding Epsilon GC.

In this article, we explore a particularly intriguing option in Java Garbage Collection (GC) known as Epsilon GC. This garbage collection algorithm is notable for its distinctive feature: it performs no garbage collection. The Epsilon garbage collector (GC) was included in JDK 11.

But what is the use of a garbage collector if its not collecting? (freeloader huh!!)

Nope, its actually quite useful, one such usecase as provided by Oracle blog, which I have slightly enhanced to be more helpful.

For further details, please refer to the original blog post:
https://blogs.oracle.com/javamagazine/post/epsilon-the-jdks-do-nothing-garbage-collector

The usecase: Epsilon GC is beneficial for developers who need to assess memory allocation for a particular segment of code without the aid of a profiling tool.

Primary Challenge Traditional garbage collectors can obscure accurate memory usage metrics by continuously clearing objects. This interference makes it difficult to ascertain the true memory consumption of your code.

Epsilon GC addresses this issue by acting as a non-collector. While not a garbage collection algorithm per se, it serves as a tool for understanding memory allocation by refraining from performing any garbage collection, thereby providing a clear picture of memory usage.

Note: It is important to be aware that since Epsilon GC does not reclaim memory, excessive allocation may lead to an OutOfMemoryError (OOM) in the JVM.

Below is the sample code that will be utilized to demonstrate the efficacy of Epsilon GC.:

public class EpsilonDemo {

    public static String formatSize(long v) {
        if (v < 1024) return v + " B";
        int z = (63 - Long.numberOfLeadingZeros(v)) / 10;
        return String.format("%.1f %sB", (double)v / (1L << (z*10)), " KMGTPE".charAt(z));
    }
    public static void printmem(){
        System.out.println("*** Free MEM = "+formatSize(Runtime.getRuntime().freeMemory()));
    }

    public static void main(String[] args) {

        final int MEGAABYTE = 1024 * 1024;
        final int ITERATIONS = 80;

        System.out.println("Starting allocations...");
        printmem();

        // allocate memory 1MB at a time
        for (int i = 0; i < ITERATIONS; i++) {
            var array = new byte[MEGAABYTE];
        }

        System.out.println("Completed successfully");
        printmem();
    }
}

Expectation:
The code allocates 80MB of byte type objects. We should be able to observe the same with the print statements when we execute the code.

Now to run the compiled version with/without EpsilonGC:

Running with G1GC:

java -Xms100m -Xmx100m -XX:+UseG1GC  EpsilonDemo
Starting allocations...
*** Free MEM = 102.2 MB
Completed successfully
*** Free MEM = 74.2 MB

So with G1GC we see an incorrect allocation picture of 28 MB utilization

Running with EpsilonGC:

java -Xms100m -Xmx100m -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC EpsilonDemo
[0.004s][warning][gc,init] Consider enabling -XX:+AlwaysPreTouch to avoid memory commit hiccups
Starting allocations...
*** Free MEM = 99.4 MB
Completed successfully
*** Free MEM = 18.7 MB

Here you can clearly see 80.7 MB utilization

I hope this helps you see how EpsilonGC can be super handy for spotting memory usage patterns in your code. Cheers! 😊

Apache Kafka Kraft Protocol

Vishalendu Pandey — Sat, 30 Dec 2023 19:16:22 +0000

This document that I created was mostly for self reference, I wanted to try out the shiny and new Kafka Kraft protocol where you dont need to deploy Zookeeper and Kafka containers themselves are self-sufficient, which simplifies deployment and improves on performance as well.

Before going through with this article, I would highly recommend that you go through the following video to get familiarized with what Kraft is all about, its a very brief and to the point explanation of the topic:

The Setup using docker-compose

Pre-requisites:

Machine with sufficient resources for 3 docker containers.

Docker and docker-compose setup.

Kafka binaries setup on a seperate machine, for performance tests on the cluster.

The docker-compose.yaml needed to setup and some basic configurations are provided at my github repo:
https://github.com/vishalendu/kafka-kraft-cluster-setup

Please go through the readme file to setup the Kafka Kraft cluster.

Disclosure:

I have used a mini-pc having a Ryzen 7 5800H (8-core/16-threads) with 32GB of RAM and 2TB of M.2 NVME SSD with Sequential Read/Write up to 3,500/2,900 MB/s as my testbench. The docker containers deployed share the same SSD for storage (which can be IO limiting). Max network transfer from this machine reached 110 MB/s, so it could also be Network limited.

Some performance tests on producer/consumer

Just to checkout the performance of the consumers and producers I have provided some basic commands in the repository

https://github.com/vishalendu/kafka-kraft-cluster-setup/blob/main/benchmark.md

Just for fun -- compared producer performance with different compression algorithms

You can find the comparison in the compression-comparison.xlsx in the repo.

Summary:

The Kraft protocol is going to be the only option from Kafka 4.0 onwards, so its definitely good to get some hands-on exercise to look at what changed and how the performance characteristics of Kafka have evolved.

The Kraft protocol has improved Kafka performance beyond the point where a small cluster can support millions of partitions, whereas older Zookeeper based implementation had major performance limitations with higher number of partitions.

It was also nice to run some producer compression tests to confirm that 'zstd' is the suitable compression algorithm that gives the most bang for the buck in terms of CPU utilization and the compression ratio.

Things to do:

Would like to look at migration to Kafka 3.6 from older versions.
Will need to read documentation on consumer/producer properties if any have changed between versions or for Kraft protocol.
Need to do some High Availability tests to look at how brokers and controllers are going to handle failures. I expect better recovery performance with Kraft protocol.

How to query JMX from Jolokia REST Interface

Vishalendu Pandey — Tue, 07 Nov 2023 14:44:24 +0000

A lot of people use Jolokia to export their JMX MBean data to a time series database.
This is specially useful for applications like Hazelcast cache, where the community version of the application doesnt provide an out-of-the-box monitoring interface like management center (limited to enterprise license)

When you use Jolokia to expose your JMX mbeans, it provides a REST interface which you can

directly query,or
use telegraf to send the metrics to a Timeseries Database like Influx or
use Prometheus to scrape.

Here is a quick guide on how to query some metric from the REST interface when you have limited information.

1. How to find a MBean?
For example, here we will use search API and regular expression to search for an MBean:

curl
http://localhost:8087/jolokia/search/java.lang:type=MemoryPool,name=G1*

{"request":{"mbean":"java.lang:name=G1*,type=MemoryPool","type":"search"},"value":["java.lang:name=G1 Eden Space,type=MemoryPool","java.lang:name=G1 Old Gen,type=MemoryPool","java.lang:name=G1 Survivor Space,type=MemoryPool"],"timestamp":1699355487,"status":200}

Here you can see that starting with G1 there are multiple MBeans. Lets see if we want to check some attribute inside "G1 Eden Space". But what are the attribute names?

2. How to get the attribute names for a MBean?
Using the list API

curl http://localhost:8087/jolokia/list/java.lang/name=G1%20Eden%20Space,type=MemoryPool

{"request":{"path":"java.lang\/name=G1 Eden Space,type=MemoryPool","type":"list"},"value":{"op":{"resetPeakUsage":{"args":[],"ret":"void","desc":"resetPeakUsage"}},"attr":{"Usage":{"rw":false,"type":"javax.management.openmbean.CompositeData","desc":"Usage"},"UsageThresholdCount":{"rw":false,"type":"long","desc":"UsageThresholdCount"},"MemoryManagerNames":{"rw":false,"type":"[Ljava.lang.String;","desc":"MemoryManagerNames"},"UsageThresholdSupported":
..... shortening the output

So in this output we can see all the attributes that are available for the "G1 Eden Space", how to find "PeakUsage" attribute value?

3. How to find the value of "PeakUsage" attribute?
Using the read API:

curl
http://localhost:8087/jolokia/read/java.lang:type=MemoryPool,name=G1%20Eden%20Space/PeakUsage

{"request":{"mbean":"java.lang:name=G1 Eden Space,type=MemoryPool","attribute":"PeakUsage","type":"read"},"value":{"init":226492416,"committed":2696937472,"max":-1,"used":2566914048},"timestamp":1699367905,"status":200}

Note:

- In this article, we are using port 8087 as configured inside Telegraf.conf for jolokia plugin.

- You can connect to the JVM's JMX port using jconsole to be able to look at metrics. But by querying the data, you can write automation to alert you on certain conditions. Or monitor the data using InfluxDB/Grafana.