7 ms·

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

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 https://youtrack.jetbrains.com/issue/IDEA-247824

darksaints 5y ago
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.
- melony 5y ago
  I don’t understand why they are not shipping their own bespoke GC to go with Intellij, Jetbrains is already building their own JVMs.
- astange 5y ago
  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/jbr17_0_1b164.8 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).
  - vips7L 5y ago
    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.
  - 5e92cb50239222b 5y ago
    Text can look pretty bad if you're using other JVMs without their patches.
    - hawk_ 5y ago
      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.
      - The_rationalist 5y ago
        A part of their patches (at least for emojis?) got recently merged
    - belter 5y ago
      What are they doing in the JVM to make text look good?
  - parhamn 5y ago
    Curious before I try it, is the speed/performance any better?
    - astange 5y ago
      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.
- lmilcin 5y ago
  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.
  - darksaints 5y ago
    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.
    - lmilcin 5y ago
      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.
      - darksaints 5y ago
        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.
- pjmlp 5y ago
  They are in bed with Google, so they need to spend their resources improving Kotlin use cases instead.
Ind007 5y ago
It is defaulted to G1 now(I have 2021.2.2 version).
- Erlangen 5y ago
  I am running 2021.2.3 now. `ps aux | grep GC` still shows "-XX:+UseConcMarkSweepGC"
  - finalfantasia 5y ago
    They changed the default garbage collector to G1 last year.[1] [1] https://github.com/JetBrains/intellij-community/commit/edf1c0593e4a4655a0eeda2302f8089e155c8f8c https://github.com/JetBrains/intellij-community/commit/edf1c...
  - stusmall 5y ago
    -XX:+UseG1GC on my install of clion. Maybe old JVM parameters have persisted in settings somewhere?
    - cesarb 5y ago
      > 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.

darksaints 5y ago

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.

melony 5y ago
I don’t understand why they are not shipping their own bespoke GC to go with Intellij, Jetbrains is already building their own JVMs.
astange 5y ago
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/jbr17_0_1b164.8 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).
- vips7L 5y ago
  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.
- 5e92cb50239222b 5y ago
  Text can look pretty bad if you're using other JVMs without their patches.
  - hawk_ 5y ago
    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.
    - The_rationalist 5y ago
      A part of their patches (at least for emojis?) got recently merged
  - belter 5y ago
    What are they doing in the JVM to make text look good?
- parhamn 5y ago
  Curious before I try it, is the speed/performance any better?
  - astange 5y ago
    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.
lmilcin 5y ago
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.
- darksaints 5y ago
  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.
  - lmilcin 5y ago
    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.
    - darksaints 5y ago
      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.
pjmlp 5y ago
They are in bed with Google, so they need to spend their resources improving Kotlin use cases instead.

Ind007 5y ago

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

Erlangen 5y ago
I am running 2021.2.3 now. `ps aux | grep GC` still shows "-XX:+UseConcMarkSweepGC"
- finalfantasia 5y ago
  They changed the default garbage collector to G1 last year.[1] [1] https://github.com/JetBrains/intellij-community/commit/edf1c0593e4a4655a0eeda2302f8089e155c8f8c https://github.com/JetBrains/intellij-community/commit/edf1c...
- stusmall 5y ago
  -XX:+UseG1GC on my install of clion. Maybe old JVM parameters have persisted in settings somewhere?
  - cesarb 5y ago
    > 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.