Bug in G1GC it performs Full GC when code cache is full resulting in overkill

[Martin Makundi]

Meanwhile, is there a feature like "Finding which methods allocated
large objects" for Sun/OpenJDK JAVA?

See http://publib.boulder.ibm.com/infocenter/javasdk/v5r0/topic/com.ibm.java.doc.diagnostics.50/diag/tools/gcpd_stackevents.html

for

-Xdump:stack:events=allocation,filter=#1k

or

-Xdump:stack:events=allocation,filter=#2m..4m


**
Martin

2013/6/3 Thomas Schatzl <thomas.schatzl at oracle.com>:
> Hi,
>
> On Mon, 2013-06-03 at 14:23 +0300, Martin Makundi wrote:
>> Hi!
>>
>> > > We seem to be suffering from humongous and something else too... I
>> > > will attempt to investigate how the cause can be captured to see if
>> > > they can be made smaller.
>> > >
>> > > Why does it need to do a stop the world instead of just making space
>> > > for the items that need to be placed?
>> >
>> > There is no reason for the current behavior other than that trying to
>> > make space using a targeted mixed collection in this case is just not
>> > implemented in G1.
>>
>> So could we improve it by adding that
>
> Yes, patches are welcome :)
>
> I think a patch needs approximately the following changes:
>
> - instead of issuing a full gc vm operation in that case, issue a
> special mixed gc.
>
> - in this mixed gc first scan the region table to find the place (area)
> where the least amount of regions need to be evacuated, ie. least total
> amount of cost.
> (If you want to optimize for performance of these mixed gcs, there may
> be other goals worth pursuing. A first prototype might just take the
> first N regions).
>
> Since g1 keeps remembered sets for all regions anyway, i.e. can evacuate
> everything at any time, there is no other limitation here I can think
> of.
>
> Put the regions into the list of evacuation candidates at the top, and
> tell g1 that it absolutely should evacuate these number of regions.
>
> - sort of pre-reserve already free regions in that area so that the
> mixed gc does not allocate into them during evacuation :)
>
> - do the mixed gc as usual
>
> - allocate the large object in that now free place.
>
> All functionality is there, things just need to be wired together
> differently.
>
>> and also allowing varying-size
>> regions, to allow smaller and larger (even bigger than 32m) objects?
>
> "Humonguous regions" already enable the use of arbitrarily sized
> objects.
>
> I am not sure what overall advantage arbitrarily sized regions would
> have; while they might solve this particular problem better (in which
> way?) they would require massive changes in the collector/VM to support
> them. Also, this would likely have a large impact on achievable
> performance. E.g. evenly sized power-of-two regions give a lot of
> opportunities for optimizations in many places.
>
> There are other options, like cutting large objects into multiple
> smaller arrays (arraylets etc), but they require compiler support.
>
> Hth,
> Thomas
>
>