G1: Young gen sizing should take short-living humongous object allocation into account

Attached is an example program (from JDK-8248783) that allocates a lot of short-living humongous objects.

After startup a significant part of allocations are short-living humongous objects, i.e. objects that are quickly discarded as they are used e.g. for (web request) output buffers. Eager reclamation will reclaim them.

However they do cause evacuation failures or worse. JDK-8248783 tried to fix this by adding young collections at some point.

An alternative change that handles this application better could be G1 taking this short-living humongous object allocation into account in its eden sizing. These object are following the weak generational hypothesis, and treating them as such would help the situation.

Something like increasing the frequency of gc (i.e. decreasing young gen) when close to using up all memory (causing evacuation failure) to more frequently reclaim those.

Directly accounting them (their size) as young gen objects (all the time) may decrease performance too much.

Also note that potentially making evacuation failure more clever wrt to in which generation to place failed regions might be an alternative, preferable solution (e.g. JDK-8140326)