Intellij uses UseConcMarkSweepGC gc, which has been deprecated since Java 9. Jetbrains is still investigating the use of ZGC. https://youtrack.jetbrains.com/issue/IDEA-247824

It is defaulted to G1 now(I have 2021.2.2 version).

I am running 2021.2.3 now. `ps aux | grep GC` still shows "-XX:+UseConcMarkSweepGC"

-XX:+UseG1GC on my install of clion. Maybe old JVM parameters have persisted in settings somewhere?

> Maybe old JVM parameters have persisted in settings somewhere?

This is an annoying behavior on at least Intellij Idea (I don't know about other Intellij products). If you ever increased its memory limit (it's an option on one of the top-level menus, and it will also occasionally suggest increasing it if it ever notices it's using too much memory), it copies the idea64.vmoptions file which contains not only the memory limit (-Xmx), but all the JVM parameters, from the binary directory to your configuration directory, and so the JVM parameters on it will be kept forever, instead of being changed when you update the IDE. The fix is easy: find that copied idea64.vmoptions file, write down the memory limit on it, remove that file, restart the IDE, and go to that top-level menu option to set the limit again. This will copy an updated set of VM options to your configuration directory.

They changed the default garbage collector to G1 last year.[1]

[1] https://github.com/JetBrains/intellij-community/commit/edf1c...

Honestly this is the most frustrating thing about Jetbrains. Stop investigating shit and just use the new JVMs already. There is no excuse for using deprecated JVMs.

Edit the idea64.vmoptions config file and use the GC of your choice. I've been running with ShenandoahGC for quite some time now and it's been working great.

Also, see https://github.com/JetBrains/JetBrainsRuntime/releases/tag/j... for a JDK17 runtime for Intellij products. I've been running this too and it works great (but does require some tweaks to the vmoptions file).

Text can look pretty bad if you're using other JVMs without their patches.

Yes particularly on Linux, any non jetbrains jdk running intellij looks awful. I don't know if the consider it as some kind of competitive advantage to not submit fixes upstream.

What are they doing in the JVM to make text look good?

I tried this last year but the version they shipped with IDEA didn't have ZGC and using an external JVM caused some weirdness in the GUI for me.

Curious before I try it, is the speed/performance any better?

It depends. There is less latency in the IDE due primarily to better GC (just as the article describes). I think the speed is better too on things like indexing the code base, but that could depend on your computer. I'm running on a 32core high end AMD system with lots of RAM, and I increase the heap setting in Intellij to 4G, etc. I think the IDE is subjectively better.

We run all our production applications on JDK17 too, which is why I push to run everything on 17.

I am pretty sure Jetbrains cares their product works well for a lot of people and they know better than you which JVM is better for their product.

It is not like it restricts what you can build with it.

We may not know their exact decision process but it is incredibly ignorant to assume they are just doing this out of laziness or incompetence.

They've already explained their reasoning, I don't have to assume anything. Their reasoning is bad:

* They've fixed long-known bugs in the JVM

* They've added sub-pixel anti-aliasing and other visual rendering enhancements.

Both of these are clear improvements on the JVM, and very likely to be accepted upstream, but instead of upstreaming them, they decided to create a long-running fork and package it as their own runtime. And like all long-running forks, they're struggling to keep up.

So we are left with two choices: abandon the hope of a functional IDE that only works well on a customized runtime, or abandon the litany of performance, capability, security, and stability improvements in the JVM standard and reference JVM implementation.

But what is your problem with this? Do you really care which JVM is being packaged or you are just picking on something that isn't a problem?

Have you had a problem running IntelliJ IDEA?

I am pretty sure that if I was distributing a very, very complex Java application for a very, very wide variety of audience (like people who aren't even developers because IDEA also caters to these people) I would distribute it with JVM packaged.

And then the user should not care which JVM exactly is being distributed. You only need to care about the end result.

Let me know the last time you cared which version of JVM is used by any of the SAS products you subscribe to.

Yes, I care. Because while jetbrains makes an excellent IDE in terms of functionality, they have extremely shitty startup times and garbage collection pauses. These are both areas that have received a lot of attention in the reference JVM in the versions subsequent to their fork. All of the performance problems literally disappear by using a newer OpenJDK version, but then the GUI starts to look and act weird.

I don't know why you would assume that I am asking for them to not package a JDK at all. That's a fucking absurd assumption, and nothing i have said has even suggested that. All I'm asking for is for them to upstream their improvements and package their IDEs with OpenJDK by default so we don't have to choose between Jetbrains improvements or OpenJDK improvements.

This is so removed from reality that it's difficult to know where to start.

For starters, sub-pixel aliasing is a standard part of the JDK and isn't a Jetbrains addition.

What exactly is stopping you from using a standard JDK17 build with Intellij? How is the IDE not functional for you when doing so? How is it improved when using the JDK17 runtime they have on their github page?

I think the Jetbrains Runtime as sub-pixel AA for Linux in particular[0].

I just tried running idea with adoptopenjdk-17 on macos, and it failed to start up, so it doesn't seem that simple.

[0]: https://confluence.jetbrains.com/display/JBR/JetBrains+Runti...

Sub-pixel rendering was added in the Java "Mustang" 1.6 release 15 years ago, long before Jetbrains started providing a custom JDK. http://www.ffnn.nl/pages/articles/java/java-2-se-6.0-aesthet...

Trying to use a newer JDK on some applications, like Intellij, may require adding entries to the idea64.vmoptions file to relax the module restrictions that were tightened in JDK 15 and 16, if that app hasn't been updated for those changes. Entries like this: --add-opens=jdk.jdi/com.sun.tools.jdi=ALL-UNNAMED might be needed.

See https://youtrack.jetbrains.com/issue/IDEA-261033 for entries that might be needed.

This is easy:

Standard Jetbrains Runtime - slow as fuck, missing a whole host of performance improvements, security updates, and bug fixes since the fork occurred back in JDK8/9 Era.

OpenJDK - ugly as sin, gui becomes glitchy, lose out on customer support channels (first thing they tell you is to use the standard jetbrains runtime)

Newer versions of Jetbrains Runtime - have to reinstall manually every time you update your IDEs. You also lose out on customer support, as they are beta software.

This isn't really a hard problem to solve: find a way to upstream your improvements to the JVM, and then package the upstreamed version. All of these problems go away, and you're even relieved of the burden of maintain a long running fork.

Yes, this is easy:

- The current JBR is JDK11, not JDK8. - You don't need to reinstall anything to use an alternative JDK with the IDE. Just set the IDEA_JDK envar to the JDK of choice. - Ugly as sin is an opinion. I use the IDE with linux on a hidpi display. Looks perfectly acceptable to me...even running with JDK18. - I just reported an issue while running with the JBR17 a few days ago. Jetbrains was perfectly responsive to my issue.

They are in bed with Google, so they need to spend their resources improving Kotlin use cases instead.

I don’t understand why they are not shipping their own bespoke GC to go with Intellij, Jetbrains is already building their own JVMs.

The GC might help, but it doesn't do magic when threads aren't used the correct way, too much stuff lands on the UI thread or synchronous IO is used all over the place.

That’s the magic of HN (or maybe it’s a form of the Baader-Meinhof Phenomenon.) When one topic reaches the front page it seems like a couple more based around it hit the front page the same or next day, which allows us to expand on what we’ve learned.

Snappiness problems are often due to lazy loading Java classes.

For example first time loading project settings takes 1+ seconds while next less than 0.5. This value might get lower later if JVM decides to optimize more some parts of UI application.

I don't think that's where the issues are. IntelliJ freezes when reindexing a project when you change branches from the command line.

Current IntelliJ uses Java11 and has gotten slower over the past few years (anecdata from my own use) - so probably not.

This is what I've noticed too. Intellij has never exactly been speedy, but it had so many great features that it was worth it compared to other slow IDEs like Eclipse. And using a basic text editor like VIM or even VS Code with a big Java project isn't really feasible like it might be in other languages like Python or Node.

However, now it is really bogging down. I'm sure it doesn't help that I've got several IDEs open along with some monstrosity of a "microservice" framework running half a dozen docker services and DBs on an older Macbook Pro, but it's true that app and OS devs tend to use all increases in CPU and ram, and so absolute performance and battery life never seems to get better over the years, regardless of how much the underlying hardware itself has improved.

VS Code is fine with with big projects, I've been using it for 2 years. The language server is Eclipse after all.

Red-Hat is behind most of the Java plugins, so their quality is quite good, there is only the pain to live with Electron.

Not just slower, also energy hugry. My m1 max running pycharm loses about 10pct of charge an hour on their crappy bundled jvm, and around 4% on the latest java17-based ones, but does act weird at times when using them. Its probably down to metal vs opengl. Disappointing.

Since 2020.x it's definitely slower. The addition of jetbrains space doesn't seem to help either and removing the plugin itself makes the whole ide unstable

I wish they would just release a light version, without all the database, spring integration, and other crap. I just want a light language server.

wouldn't community edition fit the bill? Those things you mention are the main difference with ultimate.

Not sure. I moved to VS Code + Eclipse LS and it's such a more pleasurable experience. However, it doesn't support SBT which is the build tool my company uses.

The community edition is definitely enough for sbt projects.

Any reason you're using sbt for Java projects? That's an odd combination. Anyway, I believe Metals is getting close to supporting this particular use case if you want to keep using VS Code.

For some odd reason my company chose the play framework + Java. It's one of the most baffling choices I've ever seen. I've actually managed to get the Java plugins to work with sbt, but it doesn't understand when a Scala object is imported.

Just deactivate the plugins?

Try power saving mode (look in ctrl+shift+a).

I’ve given up on IntelliJ and java-based UI’s long ago. So disappointing.

That's the right way to go. Like IntelliJ or not, Java is a legacy technology. I wouldn't want to depend on that.

Lol, you are laughably bad to think that java is legacy.

The JVM is improving with never before seen speed, has state of the art GCs, a very good JIT compiler, upcoming green threads that will make blocking code automagically unblocking and once Valhalla hits with value types, there really will be very few areas where java would not be applicable.

And on top of that, there is also Graal, which is a novel way to run and optimize mixed-language code bases.

>Lol, you are laughably bad to think that java is legacy.

Seriously. It might not be one of the hip new languages with unique features but it’s a very mature language that is well battle tested, has plenty of libraries available, and the talent pool is very deep for Java hires. It’s also something that stands the test of time —- write code in 1999 on an old Java version it will still likely run on that version today.