Gerrit Grunwald: What the CRaC - Superfast JVM Startup

In this talk, Garett Grand wall discusses JVM startup performance, focusing on improvements and optimizations introduced in recent Java versions. He explains how Java code is converted into bytecode and subsequently executed by the Java Virtual Machine (JVM), highlighting the roles of class loaders, the execution engine, and Just-In-Time (JIT) compilers. The speaker details the profiling mechanisms within the JVM that facilitate efficient code compilation and execution, including C1 and C2 compilers. He introduces techniques to enhance startup time, such as Class Data Sharing (CDS) and Ahead-Of-Time (AOT) compilation with GraalVM, and explains the concept of checkpoint restore using the CRIU project to streamline application recovery. Garett emphasizes practical strategies for Java developers aiming to optimize performance, particularly in microservice environments.

[Music] ladies and Gentlemen please welcome our next speaker Garett Grand wall presenting the topic what the crap super fast jvm start up all right what an intro yeah welcome I hope you're still alive and uh not too much filled up from the from the lunch uh welcome to the session what the crack super fast jvm start up to be honest I'm not sure why I'm in the

devops track because this is somehow related to devops but maybe not all of it uh first of all my name is Garrett gal I'm working for aul we do jvms Java virtual machines um yeah I'm a Java champion and all kinds of stuff not really that important uh we talk about Java here right at least parts of it so Java is great we have a Vibrant Community

even this is not a Java Community Conference it's it's great uh we have thousands of free open source software projects but the real star of the whole ecosystem is the Java virtual machine so because all these different languages run on that machine the question is how does it work right because to get an idea about the startup time you have to understand how the jvm works and

I try to explain it as easy as possible because you probably heard about ah Java is so slow it's old it's slow right it takes forever to start up in the cloud so so it it sucks right this is what people say um I can partly agree to it and to get a better understanding let's take a look at it so if we start with our Java

code it's in a text file do Java there you write all your code then you put that in a so-called Java C compiler and this compiler creates a class plat crossplatform class file and this class file contains so-called bite code right and this bite code can be then used by the jvm that's the main idea so then if we go from there then we have so-called class

loaders and these class loaders look way more complex than this thing here it takes the class file and loads it into the jvm memory and once it gets there and you can talk about the class loaders in a whole session so but we we don't want to go there so if we go into jvm memory from there it gets into the so-called execution engine that's one part

of the jvm and you see this is not only one part it has multiple Parts in there like the interpret the C1 jit compiler C2 jit compiler profilers and garbage collectors so we only take um a look at the right part and the two jit compilers in the meantime also known under TI compilation because before jdk7 it you have to choose between one or the other compiler

so there was the client compiler or the server compiler and then from jdk7 on you can switch it on with a flag that both compilers will be used and we will come to that so to give you an idea how that works works so as mentioned we only focus on that part and make it as easy as possible for you so we take the class file with

the bite code and then we have The Interpreter it takes this this file and interprets line by line and executes it uh in the instruction set of the CPU right and that takes some time and the jvm is watching it so it's profiling it that means it counts method calls and loop back edges so and in jdk 17 that if a method for example was called A

Thousand Times by The Interpreter and it sounds like a lot a thousand times is like this right so the jvm takes this method and forwards it to the so-called C1 compiler so it figures out okay this method is lukewarm it was used quite a lot so let's compile it right so it compiles it using the C1 compiler and the C1 compiler is that's the Formerly Known client

compiler it's made for only compile code as fast as possible don't do optimizations just even the compil code doesn't have to be very pretty or small it just has to be compiled that's the main purpose of this compiler and it's quite fast so jvm does that and then again the now compiled code is running and the jvm is watching or profiling it again and then in jdk

17 there was another threshold 5,000 times so if this code now is called 5,000 times the jvm again decides okay this is now really hot code so this is called quite a lot so it's worth passing it to the so-called C2 compiler that's the Formerly Known server compiler so and this compiler is way more complex so it's not only compiling code it uses all the profiling information

from the the former runs and then creates highly optimized code for the uh for the platform you're running on and that takes a little bit longer so it's slower than the C1 compiler and does a lot of optimizations to the code so-called speculative optimizations so the jvm is speculating on how the code will be executed but I will come to that in a second if we take

a look at this so-called execution cycle then we start with interpretation which is slow then we profile that and run it finding the hotpots then we go into the C1 compiler again profiling and then we go into the C2 compiler and then we have the fast code that's the idea and then you see this little Bridge there and that's deoptimization so with some s a little bit

weird first we take all that time to optimize code and then suddenly we de optimize it again this not happens every time and this is one of the big strength of the jvm so and let me explain why this is a really good idea deoptimization is if we take a look at code and I keep it as simple as possible you see the the flow diagram on

the right side and you see the whatever method not really important here on the left side it takes a value and based on that value it calculates the bias right and then it Returns the math log 10 of the bias plus 99 that's the idea of the method and then we make the decision if the value is greater than n we do whatever to calculate the bias

if it's not greater than nine then we say the bias equals one that's the whole thing okay so now the jvm is running the code and it figures out hm the value was never greater than n so that means only the lower Branch was called all the time right so instead of going through this if then or if else Clause here the jvm does the following it

just sets the Biers to one because it was always one and it introduces this uncommon trap thing and this is only if the value is greater than nine for whatever reason we need to go back to do something right because then it means it doesn't work anymore okay so now this is executed and we can optimize that right so we can say this is math log 10

from 100 and if you know math then you know this is two so instead of doing all the code it just returns two for whatever value you pass into that method you can imagine this is way faster than doing this if else thing every time this is Branch analysis and this is one of the speculative optimizations that the jvm is doing so the question is what happens

if suddenly the value is greater than nine so then we will call this uncommon trap and then that means the jvm will take this code throw it away and goes back to the first stuff to this one and does another optimization that's the optimization so it optimizes code and if there is whatever for whatever reason it has to De optimize it it just throws away the optimizations

and optimize again in a different way right and that makes it very flexible because with this kind of optimizations the jvm can optimize the code to the usage of the application okay if we take a look at the performance graph then you see here three colors yellow green and blue so the yellow stuff is the interpretation phase and you see it's not really a long time and

then that means these thousand calls happens very quickly and then we come into the C1 compiler phase it's compiling and optim and profiling this this stuff and then the blue one is the C2 and you see the performance gets better and better over time the longer the code runs the faster it gets and then you see these gaps on the right side you see the periodic gaps

this is garbage collection so in the jvm it's like you don't have to care about memory management it's done automatically that means the jvm takes care about all the garbage collection stuff and it stops shortly depending on the garbage collector and that means you see a little drop in performance from time to time but on the left side you see this big gaps here like trenches and

this is the de optimizations and you see once it was fast already and suddenly it drops down to zero and then directly up again that means there was code that was optimized didn't work de optimize and then optimize again we would like to go to the very far right right we would like to have stable performance we don't want to go through this ramp because that takes

time okay so that's all great as already mentioned it takes time and if we now take this to the microserver environments then it will look like this so we start up or service in a container for example first time we started up we have to go through this ramp to get best performance okay second time we started up same third time same that sucks right this is

why people uh complain Java is slow because every time you start up the service take some seconds to get to full performance okay wouldn't it be great if we can do something like that we started and the next time we start the service it just goes from there very quickly that would be great right and every time you start the service again you have full performance directly

from the start okay so there are already some solutions that that help us here if we take a short look there's first of all there's class data sharing which is something that is not really related to all the compilation and these kind of things what it does if the jvm loads all the classes and it could be thousands of classes which means thousands of files then it

takes some time for the class loader to find them and load them into the memory right and this is at startup so that means if we can get rid of it by just load them once and we store them in a specific format in one file the next start we just have to load one file which is way faster right so this is uh in principle what

class data sharing is and it came with jdk 5 already so it's it's not really new but it got really good in jdk9 um yes and we can share this these classes on every startup of the jvm this has nothing to do with optimizations in the jvm this is just loading classes and this already can improve startup time a lot and uh it only reduces the class

loading time and it could be up to two seconds faster 2 seconds is already something if you would like to know more there's a really great great blog post from a friend of mine and he does sessions just about how to tune uh CDs correctly and he has a demo where he shows how to improve startup Time by 2.5 seconds just by tuning CDs correctly and that

is worth it taking a look and I'm not sure if the session um will be provided afterwards the slides but if not you can just ping me or come to me I can give you the slides okay but remember it happens here right it's class loading only it's not really related to compilation interpretation and these kind of things all right so then there is aead of time

compilation I don't know do we have Java developers in the room oh very good so you probably heard about grvm I guess this is a head of time compilation and that means we don't have to interpret bite code right so just to make that clear for these people that are not really Java developers if you have code you can either take the code and compile it into

an application directly and then you execute it this is ahead of time compilation before you run it you compile it if you have just in time compilation that's what the jvm is doing that's the the process that we saw it's profiling code at runtime and then compiling it at runtime so one is compiling ahead of time this is this approach and the other one the jbm is

compiling at run time okay so we don't have to interpret bite codes here right there's no analysis of hotspots going on and no runtime compilation of code it's compiled before we run the application that means we have full speed from startup we have if you're on Windows you have an executable like an exf file right you can just double click bam it's there very fast and groud

VM native image does exactly this so problem solved right well not so fast aot is by definition static so that means the code is compiled as I mentioned before it is run and the compiler has no knowledge of what the code is actually doing right so it doesn't know um oh this is something wrong with the clicker here so the compiler doesn't really know what the code

is doing right so it just compiles it and does some static code analysis and then it hopes that the code is as good as possible there is one solution to make it better which is called profile guided optimization um this is the idea is instead of compiling the code directly you run it once you profile it and then you take the profile and apply it when you

compile the code to the binary and then you can do for one shot you can do optimization so if we take a look again at this graph and this is now a little bit guessing because this is very different for all the different kinds of applications then if you just do plain aot without profile guided optimization you get up to 60 70% of the jvm and this

is not really surprising because like I said the compiler can just guessing uh about optimizing ations and compile the code and then you get something but it can't be as fast as the jvm if you do profile guided optimization you can get up to 90% of the jvm you can even reach it right because then for a specific use case you do the profile and then you

apply it when you compile the code and then it's it's optimized um the problem with this whole thing is that you have to do the profile first which is that's fine the problem is this is native code it's not Java code anymore debugging is hard so it might happen that you have a test coverage of 100% every test is green in your IDE you create the native

image you start it and it breaks and then figure out what's the problem and that's the hard part that's the problem with Native images it can work for small microservices it's great if you have bigger application it can be tricky so you have to be careful okay let's take a look at a approach creu uh does someone know that ever heard of it not so that's checkpoint

ReStore in user space so let me explain what checkpoint restore is for those that doesn't know if you have a laptop and if I would now close the here and then would open it tomorrow what will happen computer will be exactly the same position right this is checkpoint restore I close the lid the operating system detect it saves the the state of the the complete system into

the onto the file onto the disk tomorrow when I open it again will take the file and load everything back to memory and I can continue working right I don't have to shut it down and restart the computer that's checkpoint restore the idea here with Creo is doing not doing it on an operating system level but doing it on an application or container level so it's a

Linux project it's part of the kernel since since 2013 so it's quite mature and it's made for freeze a running application or container in Linux and then checkpoint the state of this container to disk and at a later point you can restore from this checkpoint back into memory that's the idea restoring the checkpoint means you save the stage to a file and then you load the file

back into memory and just continue running so it's not a restart it's continue where you stopped it right that's the idea and it's already used by by open VZ that we saw in the session before mentioned um Linux containers Docker potman and others they can use creu to create checkpoint restore so if you use for example Docker you can checkpoint restore Docker container and then they use

the same uh project the creu project here well it heavily relies on the proc file system which is something that is only available on Linux so you don't have that on Windows you don't have that on Mac that also means we don't have creu Windows and Mac right it's only available on Linux it can checkpoint all these things I don't read through it takes too long uh

but as you can see it can checkpoint a lot of stuff even shared memory mapped files and all these kind of things sockets it can rebuild a TCP connection from one side only so without doing the hand shaking which is quite interesting so it's a quite mature project um it doesn't come without challenges so so if you would like to restart a a checkpoint when when I

take a checkpoint on this machine which is an Arm based Mac and I take the file copy it to an Intel based Mac and try to restore it will fail the the reason is the code on this machine is is compiled for the arm architecture on an inter architecture the code won't work right I can copy the file but I can't restore it so this this doesn't

really work also if I have open files on this machine and I copy it on the same machine with the same architecture but I don't have the same file on that machine I Tred to reopen it it's not there it will fail this is the problems that you have with with creu the other thing is you can only start one instance of this application which usually is

not a problem but this is bound to the so-called pit which is the process ID on Linux so every process every program that you start has an ID which is unique and this is part of the checkpoint when I restore it and try to restore it again when it's already running it won't work work because the ID is already taken right this is another problem the biggest

problem is you would think the Java virtual machine is just an application that runs on Linux so I should be able to checkpoint and restore the jvm and you are right that works the problem is not the jvm the problem is your application because the jvm is like a runtime environment for your application so that means your application has a database Connection open your application has a

file open I create a checkpoint that means I save the state of the application and the connection to the database is still open and my file is still open now I restore from that checkpoint I try to restore it the jvm will start it will load the checkpoint it will try to run your application and then the database connection is not there and the file is not

open because it was closed when you created the checkpoint so it will break right so that's the problem so this is the problem that we try to solve with crack which is coordinated restore checkpoint and the focus is on coordination here because we make we try to solve the problem to let your application know before we create the checkpoint so that you can close for example the

database connection and then when you restore it we tell your application you know what you you will be restored right now so you you can before it happens you can reestablish the database connection so that it works right this is the idea behind checkpoint restore and that needs some modifications also in creu so we committed some code in the project to make it work so that the

jvm and creu can talk to each other it comes with a pretty simple API so you can create checkpoints using either code or J command J command comes with open jdk it's it's a little command line tool um it throws checkpoint exceptions so that means we tell you when something goes wrong where the problem was so that you might figure out okay I forgot to closer resource

for example and what we also do before we you can think about the the checkpoint like a heap dump so the Heap is part of the jvm it's the memory where all the objects are stored and before we create the checkpoint we do a garbage collection that means we compact def fragment and compact the Heap and only save the stuff that is really live all the dead

objects we don't need to save right so this is uh it's using uh so-called jvm safe points it's we don't go into detail here this is not a Java conference um this is the way you started so this is usually you start your Java application by Java minus jar and then you have an app jar you pass the parameter crack checkpoint 2 and we pass a path

a folder a volume whatever a place where the jvm should save the checkpoint this is what we tell the jvm with this command the first one and when we restore it we just call Java with this parameter and point it to the same folder and Java will figure out oh there is a checkpoint so I restore from the checkpoint right so the the lower part is the

one so that's the way how to restore start application and the upper one is how you start it okay so the API pretty simple it just has one interface this interface only has two methods before checkpoint after restore pretty simple and it's only made you implement that in your uh classes where you have resources like open files database connections whatever socket connection you have and then um

the application receives call backs during the checkpointing um if you have implemented this resource interface and then you can react on that that's the idea so that makes it possible for you as a developer to close resources in the before checkpoint and reopen them in the after restore that's the idea behind um to make that really work somehow the jvm needs to know that you have a

resource just implementing the interface is not enough because you can Implement an interface but the jvm won't really check all the classes right so you have to tell the jvm you know what here I'm a I'm a resource I would like to be notified so therefore you need to register it in the so-called context and this is pretty simple because there's only one you get it by

core. getet global context and then you can register your resource into that context and then your resource will be notified that's the idea so this is how it works you implement the interface you register in the uh in the global context and then afterwards you will be notified by the jvm when there is a checkpoint or when there was a restore all right creating a checkpoint so

now we know how to start it with the parameter we know how to restore it but how to create the actual St the actual checkpoint so it's pretty simple so if we use J command then you have your application running so the idea is you have your micros service for example in cicd you run it and then you have to warm it up right because you would

like to get rid of this curve right so it means you do something with your application apply some workload run all the tests whatever you have to touch as much code as possible to make it better and better from the compilation point of view and once you did that the code gets faster and faster and when you realize now it's fast enough you can trigger the jvm

by calling J command so what it does it passes the command jdk do checkpoint to the running jvm and you can to figure out which application it should checkpoint you just pass either the jar name of your application or the pit because your process has an ID on Linux so you pass the pit and then it will create a checkpoint of that application that means it will

call the before checkpoint you close all the resources then it will store the stuff it will stop the the jvm garbage collection save everything to the disc and shut down that's the main thing and then you can deploy this checkpoint with your container to your um whatever cluster or where you run it and then you will restore it from there the next time you start and you

can also do it from code um some people ask okay if it shuts down the jvm what's the reason I mean when I put that into my code base then it will shut down every time it touches this code what we usually tell people is you check the folder where you store the checkpoint before you call that method if it's empty you call it if it's not

empty you don't call it right it's as easy as that and why is that implemented so why do we have the ability to call it from code so we have customers in the US at the stock exchange and they run applications for the trading and in the evening when they shut down the the servers because they don't let it run overnight because when the market close there's

no need to run it then they have to for the next morning at 8:00 a.m. the stock exchange opens and the first trade has to be as fast as possible they can't go through this curve right so they can't really tell the customers you know what sorry but you have to wait 10 seconds before you do any trading because we have to warm up the jbm so

what they do or what they did in the past they started the server at 4:00 a.m. in the morning and run some specific code to warm it up so that it's really ready at 8: a.m. with this they can just run the code store the checkpoint and then go from there they just have to do it once and then the next day you can just started within

a couple of milliseconds that's the reason why it's also available in code because these companies have specific code to warm up the application it's not for everyone but for them makes sense bigger question is when to do the checkpoint when do you know your Java application is now as fast as possible Right usually the developers know or have some kind of an idea when it's good but

if you have no idea then this is the simplest way you can do it you can start your application with this parameter print compilation and does exactly what it says it prints out all the compilation steps Don't Be Afraid when you start it it looks terrible because in the Shell window it would like it will scroll like crazy and you can't read it because it prints out

all the compilations from the C1 and C2 compiler not The Interpreter if you do that you can make it even worse because you have to apply now some workload to the application means more compilations will happen but at some point you touched enough code and then suddenly you see there's a drop in scrolling speed right so it might even stop because everything's compiled and optimized and then

you can create uh this moment and create a checkpoint because then you know everything I usually do with my application is now done so now it's warmed up create the checkpoint make sure everything is uh as as I already mentioned it's only available for Intel and arm architectures on Linux it's not available on Windows and Mac and by the way who's running a application on a Windows

server in the cloud nobody Mac Linux probably all of you so you see it's not really the biggest problem that we have that it's only available on Linux but um some people complain and we will come to that because developers work on Windows and Mac right so to make that possible we created a library called or. crack and instead of coding against the jdk API you code

against this library right and what it does is it's designed to provide this smooth um adoption of crack so it's a mirror of the jdk do Craig API and instead of um how to explain that the best way so you can use it with any open jdk implementation it detects at runtime if the jdk supports crack or not if it doesn't support crack it doesn't call the

interfaces so you're good to go that means if I'm on my Mac coding against this API and I use the the interfaces I can compile it everything will work at runtime I can even execute the code it will never call the interface because my jdk here on the Mac because it's Mac OS as soon as I run it on a Linux machine it will figure out oh

I have crack available so I will call the interfaces and then you can do checkpoint restore so that means with this we make sure that even developers on Windows and Mac can work with this API and it will work later on on Linux right okay yeah it will forward all the calls to the jdk API in case it's available and you can get it here it's on

Maven Central I don't know if this this is the latest version might be even a newer one this uh that's possible but this is usually what you do okay if you need more information about why is my clicker not working wait huh everything is open source so it's on github.com Crack or. crack so you can look it up if you like it's not a secret and U

yeah it's available for free it's just a more convenient way to work with crack and um the bigger question is framework support because to be honest you would don't want to change your code base right so I mean you don't want to go into the code base and change it just to make crack work wouldn't be great when the framework itself would support it so you to

um if we start with quackers is someone using quackers here in the room nobody nevertheless it's a framework from redhead and they have rudimentary support so that means they have the support for interface but you have to implement everything on your own doesn't really help us here Micron not it's a little bit better if you use this framework and you use for example any jdbc connection to

a database they will take care about closing resources reopening resources you don't have to do it so that means you can just use it and you just have to tell microna that you would like to use crack and it will do the rest for you if you use spring or spring boot larger than 3.2 who's using spring here by the way yeah it's all good so if

you use spring resources you don't have to do anything they take care about closing these resources and reopen them right which is good so that means in this case if you switch to uh spring boot 3.2 or above it's you're fine you're good to go you don't even have to change your application so I have a demo and I don't do a live demo because uh we

saw it failed some time um pet clinic does someone know this application it's from Spring yeah it's their demo app and I use that to create some stuff again the clicker here it is so if we do it with a normal start then it will look like this I start up the application just by Java minus jar and then pet clinic and this is what you see

and then on the lower left you see the start time was 4.1 seconds roughly okay which is a lot I mean it's just a demo application but still okay that's the normal start um if I start from an auto checkpoint this is something that spring the spring boot guys implemented that and that's the the best thing of it if you on springbot 3.2 or above they implemented

a feature where before it loads your application it creates a checkpoint it starts the framework the huge framework right and then it starts your tiny application getting rid of the startup time of spring they implemented the checkpoint automatically after the framework was started because that's every time the same right and then they load your application let's take a look at this one so it's yeah it's a

feature in Spring 3.2 you can enable it with this uh command line parameter and creates an automatic checkpoint after start of the framework and right before the application will be started so if we take a look at that you started with this is Java and then you see the parameter and then you see the correct checkpoint too I still have to tell the jvm where should store

the checkpoint and then I start the pet teic okay so I um you see the second one is directly the restore because starting doesn't make sense when I started the second time from the checkpoint it's only 697 so roughly 700 milliseconds instead of 4.1 seconds right that means all the rest was only the framework the 600 or 700 milliseconds here this is in principle just loading the

checkpoint into memory start your application you don't have to change anything here in your application it will just work which is great but we can do even better if we do a manual checkpoint that means I create the checkpoint from the outside including my application now so that means I start the application with it with this parameter because I have to tell the J where to store

the checkpoint I warm it up I create the checkpoint using J command from the outside and then it also contains the application not only the framework in this case if I this where's the screen I already see it here this is strange so in the upper part I started up the first time you see 4.1 seconds then I use jdk command this jdk checkpoint with the pit

from the other Pro process to create the checkpoint and now I do the restore from one and again it doesn't show up I don't know why let me go back here you go 300 milliseconds this is now the framework plus your application downloaded or loaded directly back into memory so again we can cut nearly half of the uh 700 milliseconds here which is great so if we

compare that that means the normal start was fored 1 seconds the native image by the way I did the same with grm it was 500 milliseconds startup time from the Native executable automatic checkpoint was around 700 milliseconds and the manual one was 300 milliseconds it's not who's the fastest it just shows you that with CRA you can get into the same range as native images right which

is quite interesting and you don't leave the Java world so you still can debug it it's just your application you don't have to change even code for this I was also keen on how large is it right so and you see the native executable this is from Spring native I don't know why it's so big it's 185 megabytes for the pet clinic the jar file was 57

megabytes and the runtime was 150 so that leads to 270 megabytes for the plain Java version plus the checkpoint okay the checkpoint you have to keep in mind we have to startall two that was in this case 250 megabytes for the checkpoint because uh I didn't really set any parameters this all default settings you can strip it down because for this one you don't need a heap

that big but that means the deployment size is pretty much the same as a native image in this case plus the checkpoint but you have to store the checkpoint only once in your cluster because every service can get it from there it doesn't have to be in the docker image summary the whole correct thing is open jdk project so it's in the open jd. org projects crack

you can look it up it's led by aul it's not in open jdk yet so we will create a Jep so this is a process to get something into open jdk but at the moment you have to build it your own or you just use the build that provide and it's a way to pause and restore a jvm based application it doesn't require a closed world as

with Native images native image needs to know all the classes before it can comp compile it right so reflection is the hard part in Native image it's extremely fast I I don't know why it doesn't show up so yeah extremely fast to full performance level and there's no need for Hotspot identification method compiles recompiles and de optimizations because that was done before you create the checkpoint you

do that only once and once you restore it everything is in the checkpoint that is already optimized you don't have to go through that to that uh ramp again okay so it's improved throughput from start it's an open jdk project and it can even save infrastructure cost so you probably know this if you deploy Java in the cloud you saw that probably CPU utilization on the y-axis

and time on the xaxis and then you see this peak in the beginning when you start up a Java application this is jvm startup time and this is mainly interpretation compilation overhead that is needed because the application is running and at the same time it's interpretation compilation optimization that takes some time the warm up right once you reach that that optimized level here then you see hm

if we create a checkpoint at this position right then we can directly afterwards restore from there and then we don't need this CPU utilization anymore because then we only need maybe 50% of the CPU that can really save a lot of money because this is probably what companies do sometimes they they put a lot of CPU nodes just to get rid of this peak and once it's

running they don't need it anymore so with this you you don't even need all these CPU nodes in the beginning so it eliminates startup time and the CPU overhead memory footprint is still the same no difference if you want to know more github.com crack you will find everything there and even more demos we have demos where you can run it even with with um I think lambas

don't work anymore because Amazon changed something because they have snapart which is very similar to this but we have other demos um with spring boot with quos you can play around with this stuff and figure it out on your own and if you would like to have downloads with support for that you can get it from iso.com and that's it so now we have time for questions

if there are questions yes and we have questions and even I see a bit sorted now with additional like yeah uh how does it deal with uh inflight connections uh websockets Etc in the waral phase and after restoration uh if it uh needs some real world traffic to be effective um as as I said so whatever is needed to warm up your application you have to do

that at the warmup right either you mock it or you have real services that go to your application at warmart face this depends on you and on your application there's no General way how to do it it really depends on the application if you have a web socket or if it's a whatever other socket connection doesn't really matter here if you if you need that to warm

it up you have to figure out a way to warm up this part of your application I would suggest you mock it in in some kind of specific program that you use at the build or um build process in C ICD um and then you have to of course close the socket connection and reopen it after restore yeah I think that should answer it okay thanks uh

another question before seru uh your presentation it it appeared at this time so does the yva version affect startup time the Java version itself um Java got faster over time definitely so if you have Java 8 and you just move forward to Java 11 17 and 21 the startup time will be faster um we provided from jdk 17 upwards so 17 21 they all get crack support

so it it is faster and you should use 17 or 21 to get the best out of it okay very similar and I think it might be already answered but is there any uh one Golden Rule that will make the startup time faster no I wish there would be there's there's not this Golden Rule and it really depends on your application so and not everybody needs crack

it's really if if you suffer from startup time in microservice deployments in the cloud then it's a good idea to take a look at it apart from that if you run um application server that you start once a month you don't need it right so is okay still two questions so let's go one by one how does typically pipeline using crack look like where is the checkpoint

uh build uh to make it usable at prod yeah so what you it depends on your setup but usually what you can do you have your pipeline you start up the process that means you start your jar and you create the checkpoint by code and then you store the checkpoint or you can either create it by a script doesn't matter at the build process you build it

you run it you warm it up with whatever code you have and then you create the checkpoint and store the the checkpoint itself outside of the container right somewhere in your environment in your build environment then you start the whole thing again you build your application then you take the checkpoint and deploy to The Container this could be one setup the other thing could be you take

the checkpoint and deploy it directly to your cluster volume could also be a way so this is usually you have to find a way to run the application warm it up create the checkpoint and then store the checkpoint either in the container or somewhere in your deployment volume yeah there's a yeah sure sure sure yeah yeah but usually you can't do that right you can't really shut

down your production server because you would like to create a checkpoint for this case we could even run and create a checkpoint in the background so keep the application running and just create a checkpoint you could use this one but we we have lots of customers and they have code to mock the application usage from the outside so they have code to do that or scripts that

just handle this workload for your application to warm it up but that really depends on your workload there's I think there's one more right yeah one more but at least we have like time schedule so I would propose this question to take Garrett like personal and then ask him like uh here somewhere like around so yeah thank you for the presentation warm Applause from your audience here

to