Comment by adrian17
19 hours ago
> Imagine, for example, if the JVM needed a bunch of JEPs for JIT improvements.
FWIW, I definitely can find a bunch of both PEPs and JEPs for internal optimizations, random examples:
19 hours ago
> Imagine, for example, if the JVM needed a bunch of JEPs for JIT improvements.
FWIW, I definitely can find a bunch of both PEPs and JEPs for internal optimizations, random examples:
You can find those JEPs, but frankly they are there for 1 of 2 reasons.
1. An outsider to the regular OpenJDK dev team proposing an optimization.
2. Advertising for a cool new performance tweak with potentially large impact.
You'll also notice that the JEP descriptions are very different from PEP descriptions.
Probably the largest JEP for the JVM, Valhalla
https://openjdk.org/jeps/401
Does not have the same level of requirements being asked of the Python JIT. Further, it's well understood that this JEP will "live on main" for quite some time in preview before it's accepted and merged.
What the JEP does, instead, is simply describe the feature and potential risks.
The vast majority of JVM optimizations do not get a JEP.
Fair, I don’t argue with that, I’m not knowledgeable about Java’s processes. Just one thing:
> The vast majority of JVM optimizations do not get a JEP.
In Python too. Still, the JIT really is just a really big thing. I don’t know if there could be a better way to do it, as either 1. You develop it off-branch and… make an enormous PR when you’re done, with risks of getting rejected anyway? Or 2, you allow more experiments on main like Rust, but then you end up with hundreds of minor half-maintained nightly-only features, possibly conflicting with each other, and eventually go through bureaucracy to remove them anyway.
So, I'd grant that it'd probably be a JEP for java (the initial JIT) but not that every change to the JIT would result in a new JEP. Java's JIT, hotspot, was integrated right before they started the JEP process. The JEP for the JIT would likely be pretty boring like "It's a JIT, it does this, in some applications we see this sort of speed up". Much like the AOT JEP https://openjdk.org/jeps/514
The Java governance allows for a lot more open ended projects with follow ups. Not that it's reckless, Valhalla is proof of that, but rather that once something is good enough they are pretty open to just shipping it as a preview feature and refining until it is worthy of being stable.
That's why, for example, we saw ZGC get merged, and then JDK after JDK seeing continuing development and improvement on ZGC (Or G1 for that matter). These GCs were fairly rough on their first release and now they are pretty much best in class.
I see a Python JIT as the same thing. Delivering the infrastructure for a JIT would need a PIP, but I wouldn't put in things like "acceptance criteria" beyond "doesn't break older code". I would expect such a project to get continual updates without PEPs.
2 replies →