Continuous delivery makes JVM JIT an anti-pattern
blog.astradot.com
Continuous delivery makes JVM JIT an anti-pattern
1–10 of 37 posts
Re: Continuous delivery makes JVM JIT an anti-pattern
#2> Go and Rust encourage use of static method calls
Not having worked in Go or Rust but having done a lot of work in Java and C/C++, I'm curious how this works out in practice. My experience with developers who default to static method calls rather than objects in Java or C++ is that they also default to static (and therefore global) data as well. Of course, you don't have to do that: you can pass pre-transaction data structures to the static functions and let them operate on them, but that's what object-oriented programming is for in the first place.
Re: Continuous delivery makes JVM JIT an anti-pattern
#3> Go and Rust encourage use of static method calls Not having worked in Go or Rust but having done a lot of work in Java and C/C++, I'm curious how this works out in practice. My experience with developers who default to static method calls rather than objects in Java or C++ is that they also default to static (and therefore global) data as well. Of course, you don't have to do that: you can pass pre-transaction data…
Rust is not object-oriented.
You can make "virtual method" calls in Rust (dynamic dispatch through a "trait object", a vtable). This is explicit though, the type will look like `Box` where Java says `MyInterface` (box = object allocate on heap, dyn = virtual method calls).
I think you might be misunderstanding what "static method call" means: in this context, it means a method which is not "virtual" (in C++ parlance), not a method which is "static" (in C++ parlance, e.g. not called on an object).
Re: Continuous delivery makes JVM JIT an anti-pattern
#4>Molding a 25 year old runtime ecosystem to adapt to AOT compilation feels like putting lipstick on a pig.
Other JVMs like J9 have had AOT support for decades now, its not "lipstick on a pig". There's plenty of material from previous JVMLS meetups about AOT.
Re: Continuous delivery makes JVM JIT an anti-pattern
#5Every serious Java based Web App I've ever worked on had a prewarm step or continuous probing setup for exactly these issues. It isn't unique to Java either - lots of languages have lazy library or dependency loading, or runtime caching of external files or the like that you want to do before you start serving requests.
Re: Continuous delivery makes JVM JIT an anti-pattern
#6> 74% of containers have lifespans ≤ 1 hour
This sounds like a design flaw in the architecture. You don't tear down a house to replace a lightbulb.
Re: Continuous delivery makes JVM JIT an anti-pattern
#7Every serious Java based Web App I've ever worked on had a prewarm step or continuous probing setup for exactly these issues. It isn't unique to Java either - lots of languages have lazy library or dependency loading, or runtime caching of external files or the like that you want to do before you start serving requests.
Or a cache to be loaded. In related news, "Continuous delivery makes caching an anti-pattern".
Re: Continuous delivery makes JVM JIT an anti-pattern
#8> Go and Rust encourage use of static method calls Not having worked in Go or Rust but having done a lot of work in Java and C/C++, I'm curious how this works out in practice. My experience with developers who default to static method calls rather than objects in Java or C++ is that they also default to static (and therefore global) data as well. Of course, you don't have to do that: you can pass pre-transaction data…
Rust is not object-oriented. You can make "virtual method" calls in Rust (dynamic dispatch through a "trait object", a vtable). This is explicit though, the type will look like `Box ` where Java says `MyInterface` (box = object allocate on heap, dyn = virtual method calls). I think you might be misunderstanding what "static method call" means: in this context, it means a method which is not "virtual" (in C++ parlance…
You're correct, I was assuming that "static" in Rust & Go meant the same thing it meant in Java (which is different than what it means in C, of course). Thank you for clarifying.
Re: Continuous delivery makes JVM JIT an anti-pattern
#9> 74% of containers have lifespans ≤ 1 hour This sounds like a design flaw in the architecture. You don't tear down a house to replace a lightbulb.
Nor do you spent 10 hours with a magnifying glass and tweezers to attempt to change the filament on a burnt out light.
Which analogy you consider spurious likely depends on what kind of theatres of IT war you've been in.
Re: Continuous delivery makes JVM JIT an anti-pattern
#10Others have raised good points, but seriously something is wrong if you’re pushing updates that require restarts every hour.
I get the idea of “continuous deployment”, but this is sounding like restart-per-commit. At that point I question how much qualification and validation is happening. No one say unit tests, they aren’t sufficient, and I’ve worked on multiple projects where the pre-commit test suite runs alone can take more than an hour. Even with those tests there are semi-regular breakages.