Billy found it in time and sent me an updated version but in an effort to make him look bad, I ignored the fix. That or I simply forgot - I'll let you decide whether I'm evil or stupid. 😉
The correct text for step 3 would be: java -XX:AOTCache=app.aot -cp app.jar com.example.App ... i.e. you simply need to reference the cache created in the third step. Now excuse me while I act very passive aggressively toward @nipafx
Will Project Leyden also affect cold-start times on AWS Lamdas? I have looked into AWS SnapStart, but this look like it could be a native way to do the same thing.
AWS SnapStart is a more general approach that starts the runtime, and then has the hypervisor freeze the container and caches that image. (They'll charge you for maintaining those cached images!) I believe Leyden's AOT compilation produces a native executable. The standard Java runtime for Lambda is expecting a regular JAR file inside the uploaded bundle. So the answer is no, in the sense that I don't think it's supported by the normal Java runtime. But yes in the sense that you could still do it by providing a custom runtime. See "Building a custom runtime for AWS Lambda" in the docs. You can probably dig up the standard Java Lambda runtime so you don't have to rewrite all that.
@@nisonatic Leyden does not provide a native executable, you might be thinking about Graal’s native image. Leyden provides a cache, containing in this case, already loaded and linked classes, that the JVM reads on startup.
In general, Project Leyden wants to improve exactly such start times, but I can't guarantee that every single feature it ships does that. 😉 This one, however, does, so assuming you complete the preparation steps, you should see a start time improvement.
@@billykorando In that case you could provide that cache as part of the bundled files. I think AWS is only supporting LTS versions, so when Java 25 is out, you'd want to bundle those cache files in your .zip bundle, and update the JAVA_TOOL_OPTIONS environment variable to add the necessary -XX flags. That'd be a pretty clean solution.
When depicting 32bit java is tearing of primitives finally gone? What I mean is that the Java language defines long and double as potentially tearing. This only happens on 32bit systems. With the removal the spec could be changed to make long and double guaranteed atomic.
You mean that doubles and longs can tear during concurrent access? As I understand it, this doesn't happen on 64-bit hardware because the JVM uses atomic 64-bit writes.
Right. Note that on 64-bit hardware, this has never been a problem because there, 64-bits are always atomically written. But if your project also ran on 32-bit hw and contained code that specifically counters tearing of 64-bit values, then you could now remove that code.
Is not there any JEP for Artificial Intelligence ( Neural PUs, Graphic PUs, Tensor PUs , etc.) at the programming language Java? We could need new massive primitive types as FP32, FP16, INT8, etc and an Inter Process Communication with these AI devices.
There's no single "AI JEP", but work is being done that will further improve Java's AI capabilities. Check out projects Babylon and Valhalla as well as JEP 401.
Not sure why you guys believe all the cheap clowning around otherwise useful information is somehow worth it, like as if your target audience was in kindergarten or something.
Hi Billy, Nicolai, there is an error on the step 3 of the AOT cache
Billy found it in time and sent me an updated version but in an effort to make him look bad, I ignored the fix. That or I simply forgot - I'll let you decide whether I'm evil or stupid. 😉
The correct text for step 3 would be: java -XX:AOTCache=app.aot -cp app.jar com.example.App ...
i.e. you simply need to reference the cache created in the third step.
Now excuse me while I act very passive aggressively toward @nipafx
I love the tongue in cheek style of these videos. There enough seriousness already in the world. 👍
I love this channel, thanks for explaining everything so easy to understand.
9:34 The first good 'Integrity by default' joke I have seen!
In fact it's the only one, seems it's a niche comedy genre. But you still nailed it.
Great video, informing and entertaining at the same time!
Thank you!
JEP 404: Not Found 🤣
thanks for the update. Hopefully Oracle will make my life easy by giving us big changes like virtual threads, fixing pinning issues. :D
Will Project Leyden also affect cold-start times on AWS Lamdas?
I have looked into AWS SnapStart, but this look like it could be a native way to do the same thing.
AWS SnapStart is a more general approach that starts the runtime, and then has the hypervisor freeze the container and caches that image. (They'll charge you for maintaining those cached images!)
I believe Leyden's AOT compilation produces a native executable. The standard Java runtime for Lambda is expecting a regular JAR file inside the uploaded bundle.
So the answer is no, in the sense that I don't think it's supported by the normal Java runtime.
But yes in the sense that you could still do it by providing a custom runtime. See "Building a custom runtime for AWS Lambda" in the docs. You can probably dig up the standard Java Lambda runtime so you don't have to rewrite all that.
SnapStart is CRaC, this is completely different
@@nisonatic Leyden does not provide a native executable, you might be thinking about Graal’s native image.
Leyden provides a cache, containing in this case, already loaded and linked classes, that the JVM reads on startup.
In general, Project Leyden wants to improve exactly such start times, but I can't guarantee that every single feature it ships does that. 😉 This one, however, does, so assuming you complete the preparation steps, you should see a start time improvement.
@@billykorando In that case you could provide that cache as part of the bundled files. I think AWS is only supporting LTS versions, so when Java 25 is out, you'd want to bundle those cache files in your .zip bundle, and update the JAVA_TOOL_OPTIONS environment variable to add the necessary -XX flags. That'd be a pretty clean solution.
When depicting 32bit java is tearing of primitives finally gone?
What I mean is that the Java language defines long and double as potentially tearing. This only happens on 32bit systems. With the removal the spec could be changed to make long and double guaranteed atomic.
Great video as always, thanks!
When will instance main method be final? Get this out of Preview please!
I agree, I hope it'll be final in 25.
tell us more about the Java merch
My mom loved those Java 8 T-Shift that were giveaway when Java 8 was released
Any official Oracle Java merch ?
No, unfortunately there's no such merch. 😢
Hi Nicolai, can I assume that without 32-bit port, the tearing problem in concurrent programming will no longer be an issue?
You mean that doubles and longs can tear during concurrent access? As I understand it, this doesn't happen on 64-bit hardware because the JVM uses atomic 64-bit writes.
@nipafx Yes, this was talked about in a recent short by Jose himself
Right. Note that on 64-bit hardware, this has never been a problem because there, 64-bits are always atomically written. But if your project also ran on 32-bit hw and contained code that specifically counters tearing of 64-bit values, then you could now remove that code.
@@nipafx Well, 32-bit has been a thing of the past since last few years, all systems I've worked on are 64-bit now
@@VuLinhAssassin Right, so tearing has not been an issue for you and the removal of 32-bit ports won't change that - still no issue. ;)
Is not there any JEP for Artificial Intelligence ( Neural PUs, Graphic PUs, Tensor PUs , etc.) at the programming language Java? We could need new massive primitive types as FP32, FP16, INT8, etc and an Inter Process Communication with these AI devices.
There's no single "AI JEP", but work is being done that will further improve Java's AI capabilities. Check out projects Babylon and Valhalla as well as JEP 401.
I think it will be easier to remove taxes from the United States than to remove sun.misc.Unsafe. But good luck!
I'm pretty sure Unsafe will eventually be gone entirely. Not so sure about taxes. 😉
Not sure why you guys believe all the cheap clowning around otherwise useful information is somehow worth it, like as if your target audience was in kindergarten or something.
Because you're otherwise much less likely to watch it. May I ask (a) how you first found this channel and (b) how you found this video?
Why so serious ?