JEP draft: Remove Shark compiler (original) (raw)
| Owner | Roman Kennke |
|---|---|
| Type | Feature |
| Scope | Implementation |
| Status | Closed / Withdrawn |
| Component | hotspot / compiler |
| Discussion | zero dash dev at openjdk dot java dot net |
| Effort | S |
| Duration | S |
| Reviewed by | David Holmes, Mikael Vidstedt, Vladimir Kozlov |
| Endorsed by | Vladimir Kozlov |
| Created | 2017/10/11 14:20 |
| Updated | 2019/12/05 17:14 |
| Issue | 8189173 |
Summary
Remove Shark JIT compiler (aka LLVM based JIT).
Goals
Remove all of the Shark code under src/hotspot/share/shark, the related build machinery and occasional references to it in other places.
Non-Goals
It is not a goal of this JEP to remove the Zero interpreter (which is the basis for Shark).
Success Metrics
The JEP is successful if src/hotspot/share/shark is gone, no Shark build machinery remains under make/, and no remaining code has any referenes to Shark or LLVM left.
Motivation
The Shark code has not been updated for a long time. It requires specific old (3.x) versions of LLVM to compile, and it looks like a fairly major effort to bring it up to date with recent LLVM versions (currently 5.0). The past experiences showed that it was difficult to keep up with LLVM since the LLVM JIT API changed with every release. Furthermore, Shark has very considerable performance problems, in particular its interface with the GC is very slow. All of the platforms that Shark was originally meant to provide support for now have native C2 backends (x86, arm, ppc).
Description
Remove all of src/hotspot/share/shark and related references and build machinery.
Alternatives
An alternative would be to bring Shark up to date with recent LLVM, rewrite the Shark's interface to plug into current LLVM GC interface, and commit to maintain the result. There is currently no such commitment.
Testing
No existing jtreg tests must get broken. Any tests that possibly reference Shark (if any) need to be removed or changed to not reference Shark.