Elastic JVM improvements [Was: Re: OpenJDK G1 Patch]

[Rodrigo Bruno]

Dear Thomas,

just to add on what Ruslan already said.


> Depending on the patches' size it's probably best if you give me a
>> webrev when your names show up there and I can make them publicly
>> available.
>>
> My colleague Rodrigo Bruno will take care of it.
>

I am preparing the webrev. My OCA should be ready in the next days.
Whenever it is out, I will send the webrev.


>
>> > -Xmx Dynamic Limit Update
>> >
>> > To dynamically limit how large the committed memory (i.e. the heap
>> > size) can grow, a new dynamically user-defined variable was
>> > introduced: CurrentMaxHeapSize. This variable (defined in bytes)
>> > limits how large the heap can be expanded. It can be set at launch
>> > time and changed at runtime. Regardless of when it is defined, it
>> > must always have a value equal or below to MaxHeapSize (Xmx - the
>> > launch time option that limits how large the heap can grow). Unlike
>> > MaxHeapSize, CurrentMaxHeapSize, can be dynamically changed at
>> > runtime.
>> >
>> > For example dynamically set 1GB as the new Xmx limit
>> >
>> > jinfo -flag CurrentMaxHeapSize=1g <java_pid>
>> >
>> > Setting CurrentMaxHeapSize at runtime will trigger a full collection
>> > if the desired value is below the current heap size. After finishing
>> > the full collection, a second test is done to verify if the desired
>> > value is still above the heap size (note that a full collection will
>> > try to shrink the heap as much as possible). If the value is still
>> > below the current heap size, then an error is reported to the user.
>> > Otherwise, the operation is successful.
>>
>> One alternative here could be to use a marking cycle + mixed gcs to
>> reach that new CurrentMaxHeapSize again, which is again is a bit more
>> complicated to achieve. I can help you implementing that if interested.
>>
>> In some cases you might even get away with just uncommitting empty
>> regions and doing nothing else in response to this command.
>>
>> As Kirk mentioned, as another optimization, triggering a young gc could
>> free enough regions too.
>>
> Ok, I pass this question to Rodrigo Bruno and he has the required
> technical knowledge on the implementation.
>

It think it is definitively possible to avoid a full GC.
I only see one advantage of using a full GC, it will maximise the amount of
uncommitted memory.  However, this comes at the cost of
a potentially long pause time.

We started with this implementation because it was the minimum amount of
code changes to have this feature working.
Besides, in our use case, having a full GC is not a huge problem because
applications might be idle anyway.

Having said that, we can either push this patch with a full GC and then
work on a separate patch to avoid a full GC or improve the current
patch to avoid a full GC.

What alternative do you think is the best?

Cheers,
rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180527/2d18c9a2/attachment.htm>