Learnings from migrating a production service from JDK 8 to JDK 11
summary
Migrating the Lambda front end from JDK 8 to JDK 11 using Amazon Corretto changes memory layout (compact strings) and GC behavior (G1 default, parallelized full GC), cuts allocation per request at p99 from ~3 MB down toward ~1–2 MB, and yields p99 down 20% and p99.999 down 33% latency improvements in production. Migration requires adding JAXB, upgrading Mockito and other deps, fixing broken tests, and rolling via staged canaries across regions; rollout completes with no customer impact.
AI-written summary · about
chapters (27)
- 0:00Introduction
- 1:26Amazon Crypto Provider
- 2:16Lambda Architecture
- 4:19Measuring Latency
- 5:42Measuring Garbage Collection
- 6:33Heap Memory After GC
- 7:43Measure Application Allocation Rate
- 9:22Measure Application Allocation Rate Per Request
- 12:18What are we doing now
- 12:43Longterm support
- 13:38Strings
- 13:51String Amazon
- 14:01Coder
- 14:20String Deduplication
- 15:48Upgrading
- 16:25Broken tests
- 16:41Security
- 17:20Argument Matcher
- 17:44Makeda
- 19:00Lambda
- 21:20Staging
- 24:15GC pauses
- 24:42Compact strings
- 24:53Latencies
- 25:39Results
- 26:41Summary
- 28:07Questions
related talks
47mJava. Migrating to 11 in real app
46mGoing Java::Current in Production
55mWhy You Should Migrate to Java 11 Right Now.
50mJava 8 to 17+ Upgrade - Lessons Learned and Best Practices
42mMoving to Java 17 in production
47mOptimize your Java application for containers and serverless
19mTen things that improve the performance of your Java based AWS Lambda
53mA year with jdk11 in production.