[HN Gopher] Finding Java Thread Leaks with JDK Flight Recorder a...
___________________________________________________________________
Finding Java Thread Leaks with JDK Flight Recorder and a Bit of SQL
Author : gunnarmorling
Score : 135 points
Date : 2023-03-04 13:57 UTC (9 hours ago)
(HTM) web link (www.morling.dev)
(TXT) w3m dump (www.morling.dev)
| sgt wrote:
| For a split second there, I thought a post-airline accident
| flight recorder had some Java heap dumps that showed major issues
| and thread leaks.
| marginalia_nu wrote:
| Say what you will about Java, but its tooling is not lacking.
| nih0 wrote:
| i miss the tooling so much, theres not many programming
| languages that can compete, maybe c# with the jetbrains suite
| pjmlp wrote:
| .NET with Visual Studio Enterprise. There is enough of .NET
| that Rider still doesn't do.
| whoisthemachine wrote:
| Any examples? The only one I've encountered in the last few
| years is editing .net core WinForms UIs with the visual
| editor. In every other use case of mine, Rider has
| outclassed Visual Studio.
| pjmlp wrote:
| WPF, Blend, hot code reloading, repl, mixed language
| debugging with C++/CLI, C++/CX, C++/WinRT, SharePoint,
| Dynamics, SQL Server SP, Architecture tooling, coverage
| and automatic unit tests, COM interop tooling, Azure
| workloads integrations, some of the examples that come to
| my mind.
|
| Also, when already paid for MSDN license which includes
| VS, why pay for Rider?
| whoisthemachine wrote:
| Rider has a great WPF editor (again, I would say it often
| surpasses VS in terms of code completion), and is capable
| of hot code reloading (for server code - it doesn't work
| with WPF AFAIK).
|
| I'm also not sure what you mean by "REPL" as I tend to
| think of that as a language feature, not an IDE feature
| (most read-eval-print-loops are done through a terminal,
| which Rider has).
|
| Rider also has coverage and automatic unit tests (and
| it's sibling product Resharper had it for years before
| Visual Studio added it).
|
| "Architecture tooling" could be a quite broad category,
| but as far as where I've used Jetbrains products in this
| sense, they can automatically build class diagrams and
| the like from your code, and even export them to PlantUML
| if you want.
|
| Jetbrains also offers an IDE that can handle C++ just
| fine - https://www.jetbrains.com/clion/. I don't know how
| well it handles WinRT, but I'll admit I've never had the
| need to develop or deploy a WinRT application. I do know
| that they've started building in MAUI integration [2].
|
| I'll confess I don't use Dynamics, or know what SQL
| Server SP is, but Rider has great Database tooling built
| in. I've never had a problem connecting to MS SQL Server,
| SQLite, Postgres, or MySQL databases with it.
|
| > Also, when already paid for MSDN license which includes
| VS, why pay for Rider?
|
| I guess this question is aggressively asking why someone
| would choose Rider if they already have Visual Studio
| Enterprise, and beyond it's great tooling, the main
| benefits for me are the great code completion, the
| snappiness of the UI (you can use the editor before it
| has loaded the AST), and how rare crashes are with it
| (and it has seemingly gotten even rarer in the last few
| months, I can't remember it crashing). Beyond that, if
| you have to choose between the two, an Enterprise MSDN
| license is $6k/yr [0], and a commercial Rider license +
| the other Jetbrains C# tools is $470/yr [1]. The former
| is usually a difficult question with your manager and/or
| purchasing, while the latter hardly raises an eyebrow.
|
| [0] https://www.microsoft.com/en-us/d/visual-studio-
| enterprise-s...
|
| [1] https://www.jetbrains.com/rider/buy/#commercial
|
| [2] https://blog.jetbrains.com/dotnet/2022/08/02/rider-20
| 22-2-re...
| pjmlp wrote:
| Instead of VS, buy two IDEs on top of MSDN, great.
|
| SQL Server Stored Procedures, which can be written in
| .NET, as SQL Server hosts the CLR. This includes the
| whole debugging and deployment stuff.
|
| Architecture tooling means Enterprise Architect level not
| basic PlantUML stuff.
|
| MSDN licenses are always part of Windows development
| workshops, the only question is choosing between
| professional or enterprise.
|
| So anything JetBrains is always extra.
| easton wrote:
| > The former is usually a difficult question with your
| manager and/or purchasing, while the latter hardly raises
| an eyebrow.
|
| The one thing is that everyone on your team probably uses
| Visual Studio or has a license if you're a .NET shop,
| that may not be true of Rider or ReSharper. Your manager
| is already convinced of the need for VS. (I just bought
| my own JetBrains Toolbox because I had a coupon, but my
| company will pay for ReSharper if we want it)
| yakubin wrote:
| I don't know about .NET, but REPLs don't need to have
| anything to do with terminals. One example of a REPL are
| Swift Playgrounds in XCode. Jupyter Notebooks are also a
| kind of REPL.
| whoisthemachine wrote:
| Certainly, and there are numerous REPL environments (LINQ
| Pad springs to mind), including via the console.
| rvdginste wrote:
| > paid for MSDN license
|
| I believe a lot of companies are not directly paying for
| MSDN licenses, but retrieve them for free through a
| Microsoft partnership and by fulfilling conditions to
| obtain silver and gold competencies. I think this is the
| case for a lot of smaller companies.
|
| Microsoft however is changing their partnership
| conditions by focusing more and more on Azure. To be able
| to stay a partner with similar benefits, you basically
| need to generate more and more revenue on Azure for
| Microsoft. Something that will not be doable for a lot of
| smaller companies in my opinion. And this also depends a
| lot on the focus of the company, whether it is a pure
| software development shop or also a reseller of Azure
| services.
|
| Besides that, .net development is no longer necessarily
| windows development. My current team consists of 6
| people. 1 uses Linux, 2 use OS X, 3 use Windows. We use
| Rider, Webstorm and Datagrip. We develop .net backends
| that run on a Linux app service plan. The front end is in
| Angular. The database is postgresql.
|
| A lot of the .net developers in our company asked to use
| Rider instead of the VS they get through an MSDN license.
| Most of them are Windows users. Some people clearly think
| Rider is superior to VS, myself included...
| cbm-vic-20 wrote:
| One thing I love about the JVM is that the tooling can be used
| in production if necessary- generating thread dumps, JFR
| recordings, monitoring heap usage, etc., all of this is
| invaluable when diagnosing problems.
| marginalia_nu wrote:
| Yeah, if needs must, you can even attach a remote debugger to
| a process i prod. Pretty crazy.
| [deleted]
| TYMorningCoffee wrote:
| > and the stack trace of the parent thread when starting the
| child thread
|
| That's incredibly useful. We have a strict policy of all threads
| and pools being named, but sometimes default named threads sneak
| in making it difficult to figure out where the thread is used
| for.
| Scarbutt wrote:
| HN being very anti Java, why does such many Java articles make it
| to the front page?
| ncann wrote:
| That's not my experience at all, if anything I feel like HN is
| quite fond of Java. The anti Java crowd is mostly on Reddit
| instead where it's the subject of memes and jokes and the like.
| lenkite wrote:
| Except /r/java where Java is God
| exabrial wrote:
| A lot of it is misdirected hate.
|
| In the first dot.com boom, a lot of people worked for tech
| companies, and Microsoft was the Google|Apple back then. Their
| corporate culture was dog-eat-dog nonsense, but it trickled
| down through the industry... and of course at the time Java was
| super super popular, even though _it really sucked_ back then
| (not so much now, it's quite awesome).
|
| One of the most _hated_ positions was "The Architect" who
| usually rose to the top via floating on top of a bubble of
| attrition; so rather than being promoted because you're good at
| leadership or a great person that's fun to be around or a
| technically savvy and loved to teach... these architects were
| ignorant egotistical maniacal dictators that got promoted
| merely because everyone else quit. They turned static analysis
| tools into weapons of war. They made arbitrary standards that
| really didn't work for anyone, rather than trying to work for
| someone. Everything had to be over-engineered (sound familiar?
| If not, look at today's SPAs) with
| AbstractFactoryProducerMethodProducerImplInterfaces. I worked
| at a lot of these companies, and it just wasn't a fun time to
| be in software development.
|
| Rather than people seeing the reality that Poor Leadership and
| zero charisma as the root cause, somehow people arrived at Java
| was the core problem.
|
| A lot of the things were good in their intention; for instance,
| having the whole company use tabs instead of spaces (or vice
| versa) and having a universal code formatter have the potential
| to increase communication. But instead, it was just executed
| poorly at nearly every shop and the vast majority of the
| problems got turned into Dilbert comics.
|
| But yeah, Java.
| mqus wrote:
| Maybe the commenters are "anti" and the voters aren't (more
| comments being also a detriment to getting to the frontpage)?
|
| But I don't see any real "anti" comments, only valid criticism
| and I say that as a Java dev myself. It does have its wrinkles.
| But for it's age and popularity it's still a pretty good
| language.
| pron wrote:
| JFR is one of my favourite Java features. Like eBPF but with more
| events baked into the runtime and easier to use.
|
| Gunnar has used it in some cool ways. Not just
| https://github.com/moditect/jfr-analytics, which he showcases in
| this post, but also https://github.com/moditect/jfrunit
| gunnarmorling wrote:
| JFR is just awesome. Thanks a lot for the nice words, Ron!
| Means a lot to me, coming from you.
| pjmlp wrote:
| And if my history recollection is right, originally born on
| J/Rockit JVM.
| pron wrote:
| Correct.
| exabrial wrote:
| I need to learn to use jfr apparently. Just something I've known
| existed and never used.
|
| We attach a hawtio.io jvm agent to every single prod jvm we run
| and query the agent using telegraph. (If you don't do this by the
| way, you should!) I noticed in the GUI portion of hawtio, it
| slows you to start/stop a jfr recording, but I've never messed
| with it
| nomemory wrote:
| Java is not the most appealing programming language, but you've
| got to love the JVM, the standard library, all the libraries and
| frameworks, plus the tooling around the ecosystem.
| smallerfish wrote:
| Hence, Kotlin.
| kaba0 wrote:
| Or Scala, Groovy, Clojure, Ceylon.. we have heard it a few
| times already.
| [deleted]
| pjmlp wrote:
| So when are we getting Kotlin Virtual Machine, designed for
| Kotlin?
| MattPalmer1086 wrote:
| Does the JVM impose heavy constraints on Kotlin?
|
| I ask because the JVM is an amazing bit of technology that
| has been battle tested for decades. Would be hard to beat I
| would think.
| vips7L wrote:
| One of the major issues that Kotlin faces is that it's
| hard for them to change the VM to provide a feature they
| want while Java and the OpenJDK developers have the
| freedom to either change the VM or the language to
| provide something.
| MattPalmer1086 wrote:
| Sounds like Kotlin and other JVM languages need greater
| representation in OpenJDK then, if that would be
| possible.
| tadfisher wrote:
| I don't think it's too burdensome, because they can
| emulate features until the JVM gets support. I can think
| of several:
|
| - Data classes can become JVM records with the @JvmRecord
| annotation and some additional type constraints.
|
| - Inline classes will certainly become Valhalla value
| types (hence the required @JvmInline annotation).
|
| - Nullable types are supported with compile-time checks
| and additional runtime checks inserted by the compiler at
| time-of-use, and if Valhalla adds a nullability marker to
| the bytecode, Kotlin can support it.
|
| - Coroutines/structured-concurrency already uses
| Executors under the hood, so it's likely that we'll have
| Loom thread support without any changes to the coroutines
| APIs (though the standard dispatchers will need to use
| virtual threads themselves). Coroutines themselves are
| CPS-transforms of ordinary code and don't need VM
| support.
|
| - Tail-call elimination is supported by transforming to
| trampolines, something which the JVM will probably never
| support until Java needs it.
| vips7L wrote:
| Right but, in my opinion, those all come with ergonomic
| issues from not being able to change the VM. In general
| the quality of the feature provided by Java will be
| better because of their ability to mold the VM to the
| language.
|
| For example syntactic cooperative coroutines vs
| preemptive coroutines provided by the VM. Kotlin is now
| stuck with the colored function problem and has the stack
| trace issues that the Java team is able to avoid by not
| only being able to change the language.
|
| That being said, I think they're both fine languages with
| different goals.
| derriz wrote:
| I've a couple of years of experience of using Kotlin. In many
| ways I loved it, and it would have become my JVM language of
| choice but over time I've started feeling uncomfortable about
| recommending it.
|
| The language is completely closed and controlled by a single
| commercial software company and there is no community process
| involved in its evolution and design. I had believed that
| this business model of programming language design/ownership
| died decades ago when everyone abandoned all the bespoke
| commercial languages/IDEs of the 1980s and early 1990s. The
| way Jetbrains have scuppered the attempt to provide a
| reasonable vscode plugin feels like reliving the 1990s where
| the single company providing the language spec, compilers,
| IDE and tooling for "their" language and aggressively
| prevented others from providing alternative tools and
| compilers.
|
| Also compile times are horrendous - even with modern
| hardware, the compiler barely seems to be able to manage much
| more than a few 1000 lines/sec. Again, my age means I
| remember decades ago when compilers/IDEs advertised their
| performance in terms of 100,000s of lines per second. This
| means edit/compile/debug workflow is very painful once your
| project grows to non-toy sizes.
|
| I also grew to dislike the ethos of the "community" which
| basically seemed to involve condescension and passive
| aggressive responses to to any questions regarding the design
| of language features particularly by Jetbrains employees.
|
| Kotlin is undoubtably a more "modern" feeling of development
| than Java (or C++ for example) but I'm not sure such vendor
| lock-in is worth it given many other languages are catching
| up (including Java) or exceed it. Also I used C# for about a
| year subsequently and realised that Kotlin stole most of its
| best features from C#. Languages like Rust, Zig, Swift, etc.
| are just as "modern".
| thangalin wrote:
| Here's a real-world example of using C# to create a set of file
| paths, aiming to eliminate duplicates. I'd've written this in
| Java as: Set<File> s = new HashSet<File>();
| s.add( new File( "c:/temp" ) ); s.add( new File(
| "c:/temp" ) ); System.out.println( s.size() );
|
| This prints 1.
|
| The C# code: ISet<FileInfo> s = new
| HashSet<FileInfo>(); s.Add( new FileInfo(
| "c:/temp" ) ); s.Add( new FileInfo( "c:/temp" ) );
| Console.WriteLine( s.Count );
|
| This prints 2.
|
| They are line-for-line identical. IMO, Java prints the correct
| result. C# may have reasons for this behaviour, but when you're
| looking at the code, it's not obvious that two FileInfo objects
| for the same paths are not equal.
|
| When I wrote KeenWrite[0], I chose Java because of all the
| reasons you mentioned, plus JavaFX. JavaFX is one of the
| richest cross-platform GUI libraries available for desktop
| applications, although it does have quirks.
|
| [0]: https://github.com/DaveJarvis/keenwrite
| mrkeen wrote:
| I aimed to eliminate duplicates of URLs using that approach
| in Java. Do they resolve to the same IP? Same URL.
| electrum wrote:
| Yeah, URL is from the first release of Java and should be
| avoided. You want to use URI instead.
___________________________________________________________________
(page generated 2023-03-04 23:00 UTC)