WEBVTT 00:00.000 --> 00:02.000 You 00:30.000 --> 00:59.000 Is the 01:00.000 --> 01:11.600 A Clips Tamarin, a freely available distribution of open JDK, gets downloaded more than 01:11.600 --> 01:17.680 10 million times a month across various JDK versions. 01:17.680 --> 01:25.960 JDK image size improvements could have saved them about $30,000 US dollars of hypothetical 01:25.960 --> 01:31.480 content delivery and at work costs. 01:31.480 --> 01:41.480 In this talk, I'm going to show you what made those savings possible in JDK 24 and 01:41.480 --> 01:50.640 how you as a travel developer or an application-bundler can profit from a similar savings 01:50.640 --> 01:56.520 by reducing the size of your runtime that you bundle with the application. 01:56.520 --> 02:07.560 Hi, I'm Siddling Gable, I'm a software engineer with Red Hat and about 2023, I was trying 02:07.560 --> 02:16.760 to use J-Link to create an application bundle a custom runtime for my application and at 02:16.760 --> 02:22.440 the time I had a distribution and had that didn't ship the J-mods, the package modules 02:22.440 --> 02:24.440 with it. 02:24.440 --> 02:32.400 I got disappointed really fast because it didn't work, I couldn't create my runtime. 02:32.400 --> 02:38.440 So I thought, yeah, okay, I've been working on Open JDK for a while, like eight years and 02:38.440 --> 02:45.160 then an Open JDK maintainer for, I don't know, five years this and I thought, okay, you 02:45.160 --> 02:54.840 can contribute another republic to fix this problem and imagine my surprise when it took 02:54.840 --> 03:05.120 me probably two years from the initial prototype to get this feature shipped in JDK 24 03:05.200 --> 03:07.640 with Jet493. 03:07.640 --> 03:15.000 Okay, so let's take a quick look back what changed. 03:15.000 --> 03:23.000 The past JDK was JDK-23 and it looked about like this, right? 03:23.000 --> 03:31.600 So if you download a JDK in this case I've used the clips, you see this when you extract 03:31.600 --> 03:35.840 it to a folder, go there and see some sizes, right? 03:35.840 --> 03:42.560 So the lip folder is about three quarters and there's a folder called J-mods, that's one 03:42.560 --> 03:51.400 quarter and this, this CHAP493 basically goes ahead and removes this. 03:51.400 --> 04:00.400 So you can still run J-Link, but you don't no longer need the J-mods to run J-Link. 04:00.400 --> 04:09.000 So how does that look when you compare the JDK's, JDK version 23 and an EA build of 04:09.000 --> 04:17.040 the Clips Tamarin that enables that CHAP, this is what it looks like, so the archive size 04:17.040 --> 04:26.400 is the black bar and the extracted size is the red bar. 04:26.400 --> 04:35.840 So for JDK-23 the archive size was about 200 megabytes in size and the JDK EA build 04:35.840 --> 04:44.880 is about 133 megabytes in size in the archive and extracted it's 350 megabytes and 200 04:44.880 --> 04:48.360 and it's close to 300 megabytes in size. 04:48.440 --> 04:59.880 So this got the JDK about 35% smaller in archive size and about 15% smaller extracted 04:59.880 --> 05:02.880 on disk. 05:02.880 --> 05:12.680 Hold on a little, you just said the CHAP problem is 25% yeah there were other CHAPs that 05:12.720 --> 05:21.440 got included with JDK-24 and there's one that that compressed object headers and includes 05:21.440 --> 05:30.440 a new class that a sharing archive or two and 30 megabytes each so the CHAP493 reduced 05:30.440 --> 05:40.880 it by 25% and then the CHAP 450 I think increased it a little bit again. 05:40.960 --> 05:49.960 So this is how those 25% smaller are on disk and what the CHAP promises. 05:49.960 --> 06:00.440 Okay so we have heard the Clips Tamarin could have saved 30,000 US dollars the past month. 06:00.440 --> 06:07.960 It's a hypothetical cost I did some calculation and there being being sponsored by GitHub 06:07.960 --> 06:17.040 so it's not a real one for them because I'd like to get up and what made those cost savings 06:17.040 --> 06:22.480 possible was basically those size reduction of the archive size they transferred terabytes 06:22.480 --> 06:29.600 of data every month and so how could you as a Java developer have the same benefit right 06:29.600 --> 06:37.360 if you're bundling your application with a runtime or you provide an application with a container 06:37.360 --> 06:44.760 and ship that a lot over the network then size matters and this is where custom runtime 06:44.760 --> 06:52.280 images come in. So here's this scenario in this case I've picked the Quarkes application 06:52.280 --> 06:57.240 I rest application running on the class path it requires a couple of JDK modules 06:57.240 --> 07:03.280 Java logging, Java naming, JDK unsupported so I do want to ship that application to your 07:03.320 --> 07:13.280 customers or users. Okay here's an option bundled at JDK how would that look like so we have 07:13.280 --> 07:21.560 a live application 17 megabytes in size and then bundled at JDK but is about 300 megabytes 07:21.560 --> 07:33.240 in size so there's who here uses the GRE or has heard of a GRE still 07:33.240 --> 07:41.280 a lot okay doesn't really exist anymore but there's there's many many that still shipped 07:41.280 --> 07:50.760 the chair E or what they call GRE it's just essentially it's it's it's JDK with fewer 07:50.760 --> 07:56.720 modules in it and so I put that on the jar that just to to have an idea where the JDK 07:56.720 --> 08:01.200 chair E here sits if you bundle out with their application and what you can do if you do 08:01.240 --> 08:09.640 a custom runtime. So let's draw into this this is JDK 24 right so it has 08:09.640 --> 08:20.640 jet 493 enabled and it already removes the j-mots folder. So basically 99% of the files 08:20.640 --> 08:28.600 are in the live folder now so j-mots is gone and this is how I structured it if you go 08:29.160 --> 08:35.800 and look there's a couple of s-o files without the j-m and there's a couple of other files 08:35.800 --> 08:41.720 that I just put randomly in there it's a small size right 8 megabytes in size and 10 08:41.720 --> 08:46.960 megabytes in size and there's the source tip okay a clips time range of some of the source 08:46.960 --> 08:53.880 tip it's nice if you want a debug but you can remove that it's so it's you can ship 08:53.880 --> 08:59.400 that or not this doesn't really matter here and then there's the jvm which is about 08:59.400 --> 09:07.200 6886 megabytes in size and you cannot really remove that right and then there is this 09:07.200 --> 09:14.320 live modules file right then how important megabytes wow that's almost half 09:14.560 --> 09:24.160 the size of the entire extracted trouble and what you really want to look at is how do 09:24.160 --> 09:33.040 you get this thing it's a signal file how do you get this thing smaller and yeah so what I'm 09:33.040 --> 09:39.440 getting it bundling the j-dk or the chair e which no longer exists isn't probably the 09:39.520 --> 09:48.960 best idea so here's a little observation right if you look at the default jdk it comes 09:48.960 --> 09:59.120 with a set of modules 69 of them it includes modules such as jdk hotspot agent who knows 09:59.200 --> 10:09.840 what that does a few of them and there's jdk internal ed so it comes with many modules and 10:09.840 --> 10:17.280 probably half of them you don't need and then there's if you create a runtime that only includes 10:17.280 --> 10:26.880 jvc that's that's 17 megabytes in size 21 modules okay and and and the the live modules files 10:26.960 --> 10:33.200 rings if I remove the modules if it just includes Java base I have a live modules file of 10:33.200 --> 10:41.040 30 megabytes okay but you really want to think about is go figure out what your application needs 10:41.040 --> 10:50.320 in terms of modules in jdk modules and create a custom runtime so you select the modules that you need 10:50.400 --> 10:57.520 right don't don't add the extra stuff that you never care about and you get a smaller size 10:58.880 --> 11:06.880 so in order to do that you want to use jlank okay wait the you mentioned that the j mods 11:06.880 --> 11:14.560 folder is gone and you you how do you use jlank but yeah well that was that is was what 11:15.040 --> 11:21.760 493 does it enables you to use jlank without the j mods folder and you can create a custom 11:21.760 --> 11:29.360 runtime so you get a smaller jdk download and then you run jlank on it to create a 11:30.880 --> 11:36.480 smaller runtime and here is how you would figure out this is this is this this this this 11:37.200 --> 11:42.960 interesting jdk build that enables running jlank without the j mods folder it says 11:43.040 --> 11:48.160 okay the build is linking from runtime image enabled if it's enabled it's a build time option that 11:48.160 --> 11:56.480 has to be enabled by your distributor and once it's enabled you can use it so in this case you can download 11:56.480 --> 12:04.240 this jl there and get a jdk and has it enabled so back to our application and to our scenario right 12:04.880 --> 12:11.920 you have an application that you know what modules it needs so you add add modules 12:12.480 --> 12:21.280 put those modules on a line and wait a second you probably are interested in using some other 12:21.840 --> 12:27.600 goodies right you want to you want maybe have some crypto needs or you want to do monitoring on 12:27.600 --> 12:36.320 the result or attach a debugger so in this example I've added a couple of nice nice modules 12:36.320 --> 12:43.600 that the jdk provides because I want to use the debugger and wanted to use jfr and the result 12:43.600 --> 12:49.680 ends up in runtime for a rest at and the application still runs it it's all that that it needs and 12:50.480 --> 12:56.960 that's it and if you're clear if you run the list modules command on the result it shows the actual 12:56.960 --> 13:06.000 list of modules that it's that it includes in your custom runtime okay so how does that look 13:06.000 --> 13:11.840 in terms of size of this lib models file we've we've just figured out okay this is what are in 13:11.840 --> 13:18.320 for the megabytes in size on a default jdk includes 69 modules for your custom runtime in this 13:18.320 --> 13:30.320 example it includes eight modules and 32 is 32 or 33 megabytes in size okay that reduced the 13:30.400 --> 13:38.640 lib modules file by three quarters so what does that look like if you if you compare 13:40.240 --> 13:47.120 bundling your application with a gre which no longer exists and compare it to a custom runtime 13:47.840 --> 13:56.880 so the archive size in this specific case of the small app that only was 17 megabytes in size means 13:56.880 --> 14:06.240 you have an archive size bundling the gre of 72 megabytes and an extracted size of 200 megabytes 14:06.880 --> 14:16.880 and if you use the custom runtime you're a your archive shrinks 50% and you're on this size shrinks 14:16.960 --> 14:27.680 is only 60% of the size if you bundled it with a gre remember the first a few fears earlier slides 14:27.680 --> 14:35.680 showed that there was a jdk and gre and the gre was already smaller right so this is comparing 14:35.680 --> 14:42.960 the gre that it is already smaller and so stop stop using gre bundling and you create your 14:42.960 --> 14:56.480 custom runtime okay so a clips tamarin could have saved hypothetical 30 thousand yes dollars 14:56.480 --> 15:02.800 the past month because they they get download a lot right so and that calculation is based on a 15:02.880 --> 15:15.680 30 35% archive size saving as compared to the previous jdk and if you what I've what I've shown 15:15.680 --> 15:25.600 with this small example app it it brought in a 50% size reduction and so a clips tamarin saved 15:25.600 --> 15:35.200 I think 630 terabytes of data by just a small reduction if you if you not that out to previous 15:35.200 --> 15:42.320 jdk and so what what kind of size or cost savings are you looking at if you if you bundled 15:42.320 --> 15:49.360 the r custom runtime with their application instead of the full jdk or jdk because it's a 50% 15:49.360 --> 16:02.480 reduction of as compared to bundling at jdk and so what now go and create your custom runtime for 16:02.480 --> 16:11.760 your for your application you we've seen that jdk with jdk 24e got smaller in size so you can 16:11.760 --> 16:20.320 even use it in c i c cd systems where you download the jdk and it's already it no longer 16:20.320 --> 16:26.160 ships this jdk stuff and then then you can create your custom runtime on the fly if you need to 16:26.160 --> 16:33.600 update your applications with with the latest security update so go and create your custom runtime 16:33.600 --> 16:45.600 today that's all ahead thank you 16:45.600 --> 16:56.000 any questions no it's not enabled by default so you have to you have to enable it using a 16:56.000 --> 17:09.120 configure switch and create linkable runtime or enable sorry yeah there are a couple of restrictions 17:09.120 --> 17:18.960 like one one that has been put in place that basically if you it immense it immense the jdk 17:19.440 --> 17:31.040 jdk module with a couple of files that jdk needs to look at and so if the idea was to 17:31.040 --> 17:41.040 for now disable this able creating a jdk including jdk jdk jdk if you're doing this mode 17:41.040 --> 17:47.600 because there it uses some files on the file system and if you change the configuration it 17:47.600 --> 17:54.080 fails still but but there's a certain limitations it's in the chat but for now it it just doesn't 17:54.080 --> 18:01.760 allow you by design to create another one with jdk jdk jdk if that's removed then then it will 18:01.760 --> 18:10.800 we will see what the use cases out there are to use to use the this mode instead of the default 18:10.800 --> 18:22.080 with jdk jdk the question the question better okay any more questions thank you 18:40.800 --> 18:44.080 you