New Project Proposal: The Block GC
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Sun Apr 1 07:35:25 UTC 2018
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
In accordance with the OpenJDK guidelines , this project will provide
the Block GC, a creative new approach of handling GC mis-optimization.
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
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:
-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
The first installment of the 10% payment to the OpenJDK comminuty will
be issued exactly one year from now, on April 1st 2019.
A preview of the Block GC can be found here:
The initial Committers will be: Magnus Ihse Bursie, Satoshi Nakamoto and
P. T. Barnum.
More information about the discuss