-
Cryptic error messages in Java
We are dealing with complex stuff in Plumbr. Hacking JVM internals, bytecode manipulation, data mining - we are all over it. But some of us also teach young developers. Who are doing their first steps in the Java wilderness. And year after year we see those youngsters run into the same problems over and over again. And part of those problems seems to be related with the cryptic ways Java has chosen to explain developers about the problem at hand.
Filed under: Java
-
Amdahl’s law illustrated
The article will explain in simple terms the Amdahl's law. We are going to demonstrate via a case study how throughput and latency are changing when you change the number of threads performing the tasks. We also help to draw right conclusions in the context of your own performance tuning task at hand.
Filed under: Performance
-
How to shoot yourself in foot with ThreadLocals
It will start nicely. Like most of the stories. You discover a new concept and are amazed by it’s powers. And then equipped with this new hammer suddenly everything starts to look like a nail. From what we have experienced in past months, java.lang.ThreadLocal makes one hell of a hammer.
Filed under: Locked Threads
-
How many threads do I need?
If you wish to squeeze out most from all those expensive cores you have purchased for your production site – bear with me and I will shed some light on the mysteries surrounding multi-threaded Java applications. The content is “optimized” towards the most typical Java EE application, which has got a web frontend allowing end users to initiate a lot of small transactions within the application. And significant part of each transaction is kept waiting for some external resource. Such as a query to return from the database or from any other integrated data source. But most of the content is also relevant for other applications. Such as computation-heavy modeling applications or data-chugging batch processes.
Filed under: Locked Threads
-
Selecting your Collections library
Is this really something you should bother? Is there something fundamentally wrong with java.util.ArrayList and java.util.HashMap? For most of the source code out there the answer is - no; those implementations are perfectly OK. But as always, the devil is in the details. And there exist situations when either the feature set built into the Collections API is not sufficient enough or you find the overhead provided by the standard collections to be way too high for your likings. In the past years we have continuously stumbled upon the very same problems. And thought it would be nice to share the experience – hopefully it can save somebody a day or two. Either via avoiding yet another bidirectional Map implementation or understanding why his HashSet consumes 10x more memory than intended.
Filed under: Memory Leaks
-
Looking back to 2012
This one is going to be one of the rare non-technical post. But we just closed our first year and did an internal review of what did we manage to deliver throughout 2012. So our technical readers - do not be afraid. We continue with in-depth technical articles throughout 2013. When we were done with Plumbr 2012 review, it looked like something we could also openly publish. So here we go, hopefully those of you building your own tech company can learn a thing or two from the next 900 words.
Filed under: Plumbr
-
Plumbr now verified to work on Jelastic
Modern technology is wonderful. Looking back to the early 2000’s, it seems ridiculous. We literally had to wait for months to get our hands on a new staging environment. Young developers, you should be grateful for virtualization and IaaS! You can now get happily up and running on a brand new application server within minutes. Or, so the platform providers promise. We wanted to test this promise and see whether it’s really that easy to build a virtualized environment. And, of course, run our very own Plumbr leak detector on it.
Filed under: Product Updates
-
A 12-year-old bug in JDK, still out there leaking memory in our applications
This story goes back. For weeks or even decades, depending on how you mark the starting date. Anyhow, few weeks ago one of our customers had problems with interpreting a leak reported by Plumbr. Quoting his words “It seems that Java itself is broken”. As a matter of fact, the customer was right. Java was indeed broken. But let’s check the case and see what we can learn from it. Lets start by looking into the report generated by Plumbr.
Filed under: Memory Leaks
-
Singularity is near – Plumbr 2.0 is released
We have worked hard during the past months and can now proudly present you the results. In a form of new Plumbr release. In the 2.0 version we are shipping you a complete rewrite on the core algorithms with significant leak detection improvements. The quality of leak detection algorithms is significantly increased: we now find 88% of all leaks present in the applications. This number might need a bit more insight from us. What we do behind the closed doors is a lot of (machine) learning. Free Plumbr versions send us anonymous statistics about the object creation and destruction patterns. We used this data as a training set for supervised machine learning to improve our leak detection algorithm.
Filed under: Product Updates
-
Should you trust the default settings in JVM?
JVMs are considered smart nowadays. Not much configuration is expected - just set the maximum heap to use in the startup scripts and you should be good to go. All other default settings are fine. Or so some of us mistakenly thought. There is a lot going on during runtime which cannot be automatically adjusted for performance, so I am going to walk you through what and when to tweak throughout a case study I recently faced.
Filed under: Java
