Performance

Episode 95. Ludicruos speed! Practical GraalVM

So we had a previous episode where we show a party trick with GraalVM, where we saw how to create a Native Image. It was really the “hello world” of Native image creation, so Bob decided that’s not good enough!

In this epidose we dive a little deeper on how to actually run your Restful Web service (or other app) natively, going through the exercise of debugging GraalVM builds including adding Maven plugins, finding out how to quelch the different reflection errors and how to deal with resources (and those pesky JNI / so libs).

In all, this is more of actually a practical use of GraalVM, not just a “it can do it”, but more, how is it done. So want ludicruos startup speed and performance? then press play and listen!

http://www.javaoffheap.com/datadog
We thank DataDogHQ for sponsoring this podcast episode

GraalVM Native Image Options
https://www.graalvm.org/reference-manual/native-image/Options/

Maven GraalVM Native Image Plugin
https://www.graalvm.org/reference-manual/native-image/NativeImageMavenPlugin/

Apache HttpComponents
http://hc.apache.org/

https://www.graalvm.org/docs/getting-started/linux/

GraalVM Resources
https://www.graalvm.org/reference-manual/native-image/Resources/

Build Configuration
https://www.graalvm.org/reference-manual/native-image/BuildConfiguration/

GraalVM Example Code
https://github.com/bobpaulin/javapubhouse-graal-episode/
https://github.com/bobpaulin/opencv-1/tree/feature/add-native-image

GraalVM Native Image InvalidAlgorithmParameterException
https://github.com/oracle/graal/issues/768

Don’t forget to SUBSCRIBE to our cool NewsCast OffHeap!
http://www.javaoffheap.com/

Do you like the episodes? Want more? Help us out! Buy us a beer!
https://www.javapubhouse.com/beer

And Follow us!
https://www.twitter.com/javapubhouse

Episode 94. Oh, put on your hat Dr. Watson, we are sleuthing this Heap Dump

So it happens. Sometimes a Java program just “dies” with the dreaded Out-of-memory Exception. Sometimes, it leaves behind a “heap dump”, or a copy of what the Java program had in memory when just before it throw the Out-of-memory exception. For some devs, a heap dump is stressful, because they think is a black box with only mysteries, but we are here to calm your fears!

In this episode we show how Heap dumps are your friends! If you happen to have one, then is almost assured that you can find what caused the out-of-memory, and/or you can “see” what the real values of configuration were. For troubleshooting a production incident, a heap dump becomes invaluable since “nothing” hides from it. Doesn’t matter where the code came from, a heap dump will have exactly what each variable was holding and who might be responsible for a memory leak!

“Memory leak you say? I thought java didn’t have memory leaks!”. Well, that’s the other part of this episode where we discuss while Java has way less worries than (say c++) on allocating and deallocating memory, you can still create Memory leaks by having strong referenced objects that are never removed (and if that sounded like mumbo jumbo, even a better excuse to listen to this episode)

So, we survived 2020. Take a listen to this end-of-the-year episode, and be even more ready for whatever 2021 throws at us!

We thank DataDogHQ for sponsoring this podcast episode

Don’t forget to SUBSCRIBE to our cool NewsCast OffHeap!
http://www.javaoffheap.com/

How to capture a Heap Dump
https://www.baeldung.com/java-heap-dump-capture

Eclipse Memory Analyzer
https://www.eclipse.org/mat/

VisualVM
https://visualvm.github.io/

Do you like the episodes? Want more? Help us out! Buy us a beer!
https://www.javapubhouse.com/beer

And Follow us!
https://www.twitter.com/javapubhouse

Episode 93. Not your Grandpa’s Serialization Part DEUX!

We’re back! and now we move to the new-fangled serialization and deserialization frameworks, starting with Protobufs! Google’s contribution to the serialization space, Protobuf V3 makes it easy to create a very efficient on-the-wire serialized representation of objects, and then some. With the ability to have both backwards and forward compatible changes, protobufs is a great choice for transmitting information across services.

But not to be outdone, @BobPaulin goes in and covers Thrift, which goes a step beyond than just serializing messages, but also takes care of the “Transport layer”, adding the ability of doing Remote-procedure-calls! Imagine if instead of saying “I need to send a message to that service, and then the service can process it and send info back”, you just said. “I want to call a method on that service with this parameters and get the results”. Thrift exposes that functionality by letting you have an interface that you can just call in your client service, and it “magically” coordinates all the gnarly stuff to encode, transmit, execute, decode, and present your call. You don’t even have to think (too deeply) about how it all happens. As long as you define your thrift objects, thrift methods, and Thrift transport, the framework will let you just think of methods to call! that’s it!

So in all, a very fun episode where we discover what the new types of serialization frameworks are up to. If you ever had to create a message, or ever had to annotate an object as Serializable, then do take a listen to this episode!

FOLLOW US JavaPubHouse on twitter! Where we will be sharing new tech news, and tutorials!


We thank DataDogHQ for sponsoring this podcast episode

DataDog Logo
Don’t forget to SUBSCRIBE to our cool NewsCast! Java Off Heap



Do you like the episodes? Want more? Help us out! Buy us a beer!


And Follow us! @javapubhouse and @fguime and @bobpaulin

Episode 87. Ok, it’s time to get Reactive!

It’s that Streaming-new-deal that has been taken over the web world, Reactive! You’ve heard about it, and maybe even tried to learn it a couple of times but find it confusing? Well, be confused no more since on this episode Bob and I explore the basic foundations of Reactive (and explain what is that makes is so confusing to begin with)

But that’s not all. We also dive on why is such a “hot” technology and why is the recommended approach on new microservices, even so, we also explore its drawbacks and why we shouldn’t rip everything apart to make “reactive” things.

Lastly we start exploring one of the “reactive” frameworks with Spring WebFlux, and explore how to “think” about Reactive (and came with the marble track analogy). In all, this episode will shed light on a topic that has been hard to understand, but on which, if done correctly can bring a very large performance gain!

FOLLOW US JavaPubHouse on twitter! Where we will be sharing new tech news, and tutorials!



We thank DataDogHQ for sponsoring this podcast episode

DataDog Logo
Don’t forget to SUBSCRIBE to our cool NewsCast! Java Off Heap



Do you like the episodes? Want more? Help us out! Buy us a beer!


And Follow us! @javapubhouse and @fguime and @bobpaulin

Episode 86. Move Over Slow Startup times, GraalVM…IS…HERE. (and cross-language support, and less memory footprint…)

Oh my! This episode is going to be one of our favorites. There are times where the Java ecosystem delivers something incredibly interesting (InvokeDynamic, Lambdas, Streams, Kotlin), and this episode is one of those! You may have heard it mentioned around the interwebs or conferences (this new GraalVM thing)… well, it’s here to stay and is propelling JVM languages to a whole new level of interoperatibility and performance!

So GraalVM at the very high-level view is a “Java Virtual Machine” (in reality there’s much more to it, but we can at least start there). It provides tons of interesting features, like the ability to not only compile Java/JVM languages, but also Javascript, LLVM Languages (like C++), Python, R (and is expanding to others), and more importantly, interoperatibility between all these languages.

But the bee’s knees (or the most interesting fact) is that GraalVM also have the “Native Image”, which allows you to completely bake in a Linux (more platforms coming) binary straight up from your source code. The Native Image doesn’t require Java to be installed, and you can start your application as you would any other Linux executable. The most impressive part? Startup times are incredibly fast!

So we have usually addressed tons of misinformed myths of the Java language like “It’s slow:” (No, not really), or “You can code more performant code in C++” (possibly, but you have to be an expert to squeeze more performance than the JVM’s JIT compiler). But one area that the claim has held true is that “Java has slow startup times”. And (it used to be) true! Because of the dynamic classloading that Java supports, it’s very hard for the JVM to startup fast. For long running applications this is usually not a problem, even so, for the new Cloud folks (and Lambdas, and AutoScaling Groups), fast startup time is a “thing”. And so, with GraalVM (with some caveats) we are conquering one of the last arguments against the JVM languages.

In all, THIS is the episode to listen this year. It’s exciting, new technology that we could really spin up and use. Let’s have fun programming again with GraalVM.

FOLLOW US JavaPubHouse on twitter! Where we will be sharing new tech news, and tutorials!



We thank DataDogHQ for sponsoring this podcast episode

DataDog Logo
Don’t forget to SUBSCRIBE to our cool NewsCast! Java Off Heap



Do you like the episodes? Want more? Help us out! Buy us a beer!


And Follow us! @javapubhouse and @fguime and @bobpaulin

Episode 84. Let’s get down and dirty w/Netty!

So you get that project that needs to connect to a server that doesn’t talk rest, or http(s), but has its own protocol (or maybe it DOES talk https but you are looking for incredible performance!). Well, look no further than Netty! Sure, sure, you could really spend time working with NIO.2 and creating your own sockets and all that jazz, but why? The Netty.io folks already did it, and by golly they created a library that’s “blazingly fast”.

So take a dive into this episode where we talk about the main netty concepts (like pipelines and handlers), and give you a tip or two as you embark down into protocol performance bliss. Netty has seen it all, and has been battle tested for a while now (Have you heard of Jetty? well, that has Netty under the hood), and best of all, we go over how to be “lazy” about it! Netty really implemented a lot of protocols, events, and stuff already (for example LengthFieldBasedFrameDecoder, ProtobufVarInt32FrameDecoder, SslHandler, WebSocket00FrameDecoder and much more!), so you don’t have to be the wiser and implement things from scratch… chances are… Netty already has them (or at least will have the right tools to create your own thing).

FOLLOW US JavaPubHouse on twitter! Where we will be sharing new tech news, and tutorials!



We thank DataDogHQ for sponsoring this podcast episode

DataDog Logo

We also thank OverOps for sponsoring this podcast episode

OverOps Logo
Don’t forget to SUBSCRIBE to our cool NewsCast! Java Off Heap



Do you like the episodes? Want more? Help us out! Buy us a beer!


And Follow us! @javapubhouse and @fguime and @bobpaulin

Episode 82. Uh-oh Spring… you got some serious competition from Micronaut!

So the internet is all raging about this (not so little) framework that is doing it all. Created with a “cloud-first” mentality, @Micronautfw is aiming to be your next Spring Boot! And, oh gosh, how easy they are making it.

We dive into what makes Micronaut such a darling of the internet right now (not using reflection, GraalVM ready, better memory consumption) and see how much “stuff” is in there (the TLDR; A Lot). We go from creating a microservice, to looking at the different already-implemented features like circuit breakers, properties/profiles, beans, support for lambdas, micrometer, reactive programming, and all. While it might not have “everything” that Spring does, the reality is that it’s pretty solid.

Would you consider Micronaut for your next project? The answer is maybe (and for some cases, maybe Yes). So come, and take a listen to the underdog framework (Micronaut) that’s stepping up to definitively take the reigning Champ (Spring)

FOLLOW US JavaPubHouse on twitter! Where we will be sharing new tech news, and tutorials!



We thank DataDogHQ for sponsoring this podcast episode

DataDog Logo

We also thank OverOps for sponsoring this podcast episode

OverOps Logo
Don’t forget to SUBSCRIBE to our cool NewsCast! Java Off Heap



Do you like the episodes? Want more? Help us out! Buy us a beer!


And Follow us! @javapubhouse and @fguime and @bobpaulin

Episode 65. Oh my gosh, we missed CACHING! (what a cache miss!)

What a strange omission, of all the concepts, one that all of us should always have is Caching. We have used it (and most likely we have been burned by it). Come and take a listen on how to correctly (or at least not as incorrectly) think about caching, finding out your “game plan”, and using JSR-107, or Hazelcast, or Apache Ignite or Spring. LRU? Time-based? How much memory? Long distribution tails? cacheable keys? All concepts that you should ask before creating/using a cache!

Don’t forget to SUBSCRIBE to our cool new NewsCast!
Java Off Heap

Do you like the episodes? Want more? Help us out! Buy us a beer!

And Follow us! @fguime and @bobpaulin

Episode 57. Sometimes you want to buy local, ThreadLocal that is!

Threadlocal is great! It can help you get out of sticky situations, and give you a great boost of performance and/or isolation. But with great tools comes great responsibility. Threadlocal can also be misused, and create memory leaks, or object corruption, and unknown sharing. So if you ever had seen one and never quite got what it does, or even if you were consider using one. Take a listen! And steer the people in the right way for the use of Threadlocal.

Also, Thanks Michael for pointing the issue with episode 55 and rebasing!

Don’t forget to SUBSCRIBE to our cool new NewsCast!
Java Off Heap

 

Do you like the episodes? Want more? Help us out! Buy us a beer!

Episode 56. Let’s have a frank talk about Unsafe! and why you shouldn’t (or should) use it

So you heard about sun.misc.unsafe. Even if you are in certain circles you might have heard about that it was (almost) removed from Java 9. And if you were really paying attention you would’ve heard the cries of every major Java Framework to the news. While it didn’t happen (Unsafe is still in Java 9, and possibly in Java 10+), we should dive into why is it so attractive, and creates such a divided opinion (JVM implementers want it gone. Performance nuts want it in)

Don’t forget to SUBSCRIBE to our cool new NewsCast! Java Off Heap

Do you like the episodes? Want more? Help us out! Buy us a beer!