The Transition to Apple Silicon
In June of last year, Apple announced that the Mac would transition to Apple’s own chips, called Apple Silicon. Here at PyCharm, this would mean major changes to the way we build our software. A change of this magnitude has not happened since the move from PowerPC to Intel’s x86 architecture.
Although the performance was somewhat acceptible on Rosetta 2, Apple’s new translation engine that translates the x86 instruction set to the M1’s ARM-base instruction set, it was not good enough for our IDEs.
In general, if you have a simple program then Rosetta 2 should be able to translate your program without significant overhead. However, our IDEs are built on top of our own custom Java Runtime Environment, and that is in no way a simple program.
Up until 2010, Apple bundled their own version of Java with their operating system. This meant that every time a new version of Java was released, Apple would need to patch it for their own operating system, so that it did not have any security vulnerabilities. With the deprecation of Java on the Mac, certain things such as font-rendering on retina screens became more difficult using the version of Java that Oracle released. In order to remedy this, JetBrains forked the OpenJDK project in order to facilitate better control over how the IDEs looked on Macs a well as other HiDPI screens; JetBrains Runtime was born and we bundled it with our IDEs from 2014.
The JetBrains Runtime ships with all our IDEs and although this gives us more control, it also means that we need to have a large team to maintain this codebase. Furthermore, there are many facets of the runtime, and we do not know every little crevice of it, rather we focus on the part of the code that handles the rendering of UI on screens.
M1 Enters the Chat
The change to Apple Silicon meant that we’d need to re-write a lot of JetBrains Runtime, to make sure that we had adequate performance. Although we had been experimenting with running applications on Raspberry Pi computers, this was a completely different issue; the M1 meant that ARM-based computers would soon become mainstream. Our IDEs couldn’t just run adequately on the M1, they had to run well on them.
To this end, we began to investigate how we could handle this transition with grace. It soon turned out that we had to re-write a lot of the JIT system, a core component of the JVM itself, which was something we had little to no experience in.
Eventually, we did manage to solve this issue with the help of Azul Systems. To hear the whole story, listen to the podcast, where I talk to Konstantin Bulenkov, who had to weather the storm of this fundamental change.
Subscribe to Blog updates
PyCharm 2023.3.4: AI Assistant’s Efficiency Boosters and a more powerful Django Structure tool window
This year, we are trying out a new approach with our releases, moving away from a quarterly schedule to more regular monthly feature-rich releases. This change is intended to deliver new features more rapidly and streamline the feedback process. Upgrade to PyCharm 2023.3.4 New AI Assistant…
PyCharm 2024.1 EAP 6: In-editor Code Review
Our new EAP build for PyCharm 2024.1 is now available for you to download! This new build is packed with a bunch of updates to the integration with version control systems. You can download the new version from our website, update directly from the IDE or via the free Toolbox App, or use snaps…
PyCharm 2024.1 EAP 5: Model Cards for Hugging Face Models, Updates for the HTTP Client, and More
Packed with numerous new features and enhancements, PyCharm 2024.1 EAP 5 brings extended support for GitHub Actions, updates to the HTTP Client, and much more.