One of my favourites is JEP 318:
Develop a GC that handles memory allocation but does not implement any actual memory reclamation mechanism. Once the available Java heap is exhausted, the JVM will shut down.For which scenario could this garbage collector be useful?
If you skip to the "motivations" at the JEP, i found the following very interesting:
Performance testing. Having a GC that does almost nothing is a useful tool to do differential performance analysis for other, real GCs. [...]There are other points mentioned there which are also interesting, but this performance calibration is in my opinion one of the most important ones.
One other is important too:
Extremely short lived jobs. A short-lived job might rely on exiting quickly to free the resources (e.g. heap memory). In this case, accepting the GC cycle to futilely clean up the heap is a waste of time, because the heap would be freed on exit anyway. Note that the GC cycle might take a while, because it would depend on the amount of live data in the heap, which can be a lot.This can be quite helpful for Oracle fn or for some special docker images, where a java funtion is called and after the execution the process is terminated.
Let's if this feature will get used in the future....