Commenting on 18:20. Looking at the graph alone, I agree it's obvious to focus on warmup optimization and not startup because the time spent at startup becomes just a small fraction of overall time after a handful of task repetitions. However, in the first minute of the talk, it was mentioned that the goal is to be more competitive with Go in cloud-native environments, and tacking the startup time is fundamental to achieving that goal. For example, consider a Java application that does mostly IO work and can handle many requests per second with just 100 millis of CPU after warmup. The issue is that when resources are that constrained, the startup can take tens of seconds, during which CPU usage will be pinned at 100% (of CPU allocated). This is bad because it makes it really difficult to add horizontal scaling based on CPU usage - you deploy a new version of your application, and new replicas start up, consuming 100% CPU for an extended period of time, enough for auto scaler to kick in and add even more replicas, which in turn also consume 100% CPU and exacerbate the problem. And, at least in K8s, it's not easy to cope with this. Current autoscaling settings are not enough to eliminate the issue, and you cannot disable autoscaling during deployment. What you end up doing is scaling based on a custom metric, such as requests per second, which requires much more effort to setup and get right. That's what's great about Go - you don't even need any training runs, it starts instantly and runs at peak performance from the very beginning, even if that peak performance isn't as good as on JVM. But you save a lot of time not having to setup any training runs, maintaining additional metadata (as required by GraalVM), or implementing complex autoscaling strategies.
So, is Java's dynamism an original questionable choice? that was needed at the time but now has to be maintained due to existing/legacy apps, or is it genuinely a useful feature in some use-cases, honestly i don't really know, I've never needed reflection myself, but I'm probably too high level.
Great presentation, but for time 43:32, the sampling size of 3 seems quite low to me. Statistically speaking it should have at least 10+ runs to get proper stats.
Belive me. When developer see reduced in 100k or 200k the cloud bill. All developer are happy to live in "close world java" and forget the java dynamics features.
Developers don't pay the bills most of the time and even so, it is more convenient the java dynamism than spend your time hunting reflection issues in GraalVM native with long compilation times. Its not a funny task at all...
Developers don't handle bills usually let alone pay it. Happy and "closed world java" doesn't exist today, either you begrudgingly accept it or you quit. I personally would opt for the later seeing the brittleness and maintenance nightmare of GraalVM native image configuration.
Maybe but. When your boss call you to congrats about a huge improvement in the cloud bill and every member in the team recieve 15k bonus. I am rally happy to live in the java close world. Today java running a race agains golang and rust in the cloud bill and java/jvm is losing for a lot. Today with native-image at least not lost for too much.
Good to see Mark Reinhold on stage after long time.
Commenting on 18:20. Looking at the graph alone, I agree it's obvious to focus on warmup optimization and not startup because the time spent at startup becomes just a small fraction of overall time after a handful of task repetitions. However, in the first minute of the talk, it was mentioned that the goal is to be more competitive with Go in cloud-native environments, and tacking the startup time is fundamental to achieving that goal.
For example, consider a Java application that does mostly IO work and can handle many requests per second with just 100 millis of CPU after warmup. The issue is that when resources are that constrained, the startup can take tens of seconds, during which CPU usage will be pinned at 100% (of CPU allocated). This is bad because it makes it really difficult to add horizontal scaling based on CPU usage - you deploy a new version of your application, and new replicas start up, consuming 100% CPU for an extended period of time, enough for auto scaler to kick in and add even more replicas, which in turn also consume 100% CPU and exacerbate the problem. And, at least in K8s, it's not easy to cope with this. Current autoscaling settings are not enough to eliminate the issue, and you cannot disable autoscaling during deployment. What you end up doing is scaling based on a custom metric, such as requests per second, which requires much more effort to setup and get right.
That's what's great about Go - you don't even need any training runs, it starts instantly and runs at peak performance from the very beginning, even if that peak performance isn't as good as on JVM. But you save a lot of time not having to setup any training runs, maintaining additional metadata (as required by GraalVM), or implementing complex autoscaling strategies.
I want to be a fly on the wall in the oracle meeting rooms where these discussions are taking place😔
So, is Java's dynamism an original questionable choice? that was needed at the time but now has to be maintained due to existing/legacy apps, or is it genuinely a useful feature in some use-cases, honestly i don't really know, I've never needed reflection myself, but I'm probably too high level.
Great presentation, but for time 43:32, the sampling size of 3 seems quite low to me. Statistically speaking it should have at least 10+ runs to get proper stats.
Belive me. When developer see reduced in 100k or 200k the cloud bill. All developer are happy to live in "close world java" and forget the java dynamics features.
Developers don't pay the bills most of the time and even so, it is more convenient the java dynamism than spend your time hunting reflection issues in GraalVM native with long compilation times. Its not a funny task at all...
Developers don't handle bills usually let alone pay it. Happy and "closed world java" doesn't exist today, either you begrudgingly accept it or you quit. I personally would opt for the later seeing the brittleness and maintenance nightmare of GraalVM native image configuration.
Maybe but. When your boss call you to congrats about a huge improvement in the cloud bill and every member in the team recieve 15k bonus. I am rally happy to live in the java close world. Today java running a race agains golang and rust in the cloud bill and java/jvm is losing for a lot. Today with native-image at least not lost for too much.
@@SLTRM Maybe you should not be so dependent on the cloud then...
@stcattc what? "Not be so dependent on the cloud" really? In what year are you living 2000?