New Project Proposal: The Block GC

[Magnus Ihse Bursie]

I hereby propose the creation of the Block GC Project with myself 
(Magnus Ihse Bursie) as the Lead and the Build Group as the sponsoring 
group.

In accordance with the OpenJDK guidelines [1], this project will provide 
the Block GC, a creative new approach of handling GC mis-optimization.[2]

The Block GC, also known as the Block Chain GC, is an innovative new 
system for Garbage Collection. It is a well-known fact that even though 
the JVM can be fine-tuned to employ an optimal GC method for a specific 
payload, most users do not bother to do so, or lack the technical skills 
needed to select the proper GC. The Block GC is a "parasitic" GC, in 
that it does not provide a separate GC system of it own, but instead 
selects the most optimal GC for each individual payload.

As a unique feature, the Block GC will measure and accurately calculate 
the improvement provided by selecting the optimal GC method, compared to 
the GC previously selected. Let T_gc_def be the time the user 
application is stopped during the GC for the default GC settings, and 
let T_gc_opt be the corresponding time using the optimal GC method 
selected by the Block GC. The difference T_gc_def - T_gc_opt is the 
improvement in pausetime provided by the Block GC, and is known as the 
"block gain".

The block gain can be seen as a hidden resource, available for free from 
the user of the JRE. After the GC has finished, the JRE can use the time 
provided by the block gain, with the user threads still suspended, 
without the application suffering performance regressions. In the 
initial implementation of the Block GC, the block gain was just used to 
let the JVM sleep for an amount of time corresponding to the block gain. 
This gave us a simple way to save processor cycles, and hence energy, 
thus providing a simple way for the Java user to help fight climate 
change without even noticing it.

While a noble goal, this does not really makes business sense. In the 
updated version of the Block GC, which we propose to be added as the 
default GC in JDK 11, the block gain is instead used to calculate hash 
values for popular cryptocurrencies, a.k.a. "bitcoin mining". Our 
estimates show that this can generate a significant amount of revenue; 
with a projected ~50 M downloads of JDK 11, running typical workloads, 
and with typical values for GC settings (default or misconfigured), 
$50k/day for all OpenJDK installations worldwide is not unreasonable.

This is a pure win-win scenario. The user will not notice any 
performance regression compared to the previous GC settings, and the 
cryptocurrency account proprietor will benefit fiscally.

The user can set their own blockchain account, instead of the default, 
by issuing this command:

    java -XX:UnlockDangerousOptions 
-XX:UnsupportedGCOption=new_provider_config:<path to config file>

where <path to config file> points to a configuration file in ASN.1 
format describing the blockchain account. We hope to finish the 
documentation of this file in time for the release, but if not done, it 
will not be considered a release blocker.

If a user override is not provided as above, by default, the revenue 
extracted by the Block GC miner will be stored in the Block GC Project 
account. This revenue will be divided as follows: 90% will go to the 
initial committers of the Block GC Project, and 10% will go to the 
OpenJDK community.

The first installment of the 10% payment to the OpenJDK comminuty will 
be issued exactly one year from now, on April 1st 2019.[3]

A preview of the Block GC can be found here: 
http://openjdk.java.net/preview/thisisunbelievable.

The initial Committers will be: Magnus Ihse Bursie, Satoshi Nakamoto and 
P. T. Barnum.

/Magnus

[1] http://openjdk.java.net/projects/#new-project
[2] http://openjdk.java.net/preview/thisisunbelievable
[3] https://en.wikipedia.org/wiki/April_Fools%27_Day