8276670: G1: Move and rename G1CardSetFreePool and related classes #6289

Hamlin-Li · 2021-11-08T02:09:44Z

Currently, only the card sets (remembered sets) use G1CardSetFreePool to give back memory to OS.

After JDK-8254739, this memory reclaiming mechanism could be reused by evacuation failure too. This is a preparation change to allow reuse of this code.

I plan to do this in about 3 steps to smooth the review process:

move G1CardSetFreePool and related classes to new file, rename these classes
refactor these classes to support freeing other freelist
some necessary cleanup

This is to simply move and rename G1CardSetFreePool and related classes, as G1CardSetFreePool and related classes are going to be reused outside of the remembered set, they should be factored out and renamed.
Rename from G1CardSetXxx -> G1BufferListXxx.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8276670: G1: Move and rename G1CardSetFreePool and related classes

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6289/head:pull/6289
$ git checkout pull/6289

Update a local copy of the PR:
$ git checkout pull/6289
$ git pull https://git.openjdk.java.net/jdk pull/6289/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6289

View PR using the GUI difftool:
$ git pr show -t 6289

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6289.diff

bridgekeeper · 2021-11-08T02:10:56Z

👋 Welcome back mli! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2021-11-08T02:12:21Z

@Hamlin-Li this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout rename-move-G1CardSetFreePool-out
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

openjdk · 2021-11-08T02:14:23Z

@Hamlin-Li The following label will be automatically applied to this pull request:

hotspot-gc

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2021-11-08T02:18:03Z

Webrevs

Hamlin-Li · 2021-11-08T08:01:49Z

Seems windows x64 build failure is not related to this change.

Hamlin-Li · 2021-11-10T07:06:16Z

Is some one available to have a look at this change? Thanks

tschatzl · 2021-11-10T12:04:41Z

src/hotspot/share/gc/g1/g1BufferListFreeMemoryTask.hpp

 #include "gc/g1/g1CardSetMemory.hpp"
 #include "gc/g1/heapRegionRemSet.hpp"
 #include "utilities/growableArray.hpp"
 #include "utilities/ticks.hpp"

 // Task handling deallocation of free card set memory.
-class G1CardSetFreeMemoryTask : public G1ServiceTask {
+class G1BufferListFreeMemoryTask : public G1ServiceTask {


Comment needs to be adapted.

tschatzl · 2021-11-10T12:04:59Z

src/hotspot/share/gc/g1/g1BufferListFreeMemoryTask.hpp

@@ -53,10 +54,10 @@ class G1CardSetFreeMemoryTask : public G1ServiceTask {
  State _state;

  // Current total card set memory usage.
-  G1CardSetMemoryStats _total_used;
+  G1BufferListMemoryStats _total_used;


Comment mentions "card set"

tschatzl · 2021-11-10T12:05:43Z

src/hotspot/share/gc/g1/g1BufferListFreePool.cpp

+  _source->bulk_add(*_first, *last, keep_num, keep_size);
+  _first = cur;
+
+  log_trace(gc, task)("Card Set Free Memory: Returned to VM %zu buffers size %zu", keep_num, keep_size);


tschatzl · 2021-11-10T12:06:47Z

src/hotspot/share/gc/g1/g1BufferListFreePool.hpp

+};
+
+// A set of free lists holding memory buffers for use by G1CardSetAllocators.
+template<MEMFLAGS flag>


G1CardSetAllocators

tschatzl · 2021-11-10T12:15:59Z

src/hotspot/share/gc/g1/g1BufferListFreePool.hpp

+
+// A set of free lists holding memory buffers for use by G1CardSetAllocators.
+template<MEMFLAGS flag>
+class G1BufferListFreePool {


I would prefer G1SegmentedArrayFreePool here, seeing the segmented array as the important thing (I understand that G1SegmentedArrayBufferListFreePool is too long).
I think there is already a CR to reconsider naming of all these classes, maybe add G1SegmentedArrayBufferList to the ones that need renaming; in particular I think right now that the "BufferList" of G1SegmentedArrayBufferList is kind of redundant.
Sorry for not speaking up earlier about this, but it only came to my mind right now.

It would be great for that renaming CR to start a thread in hotspot-gc-dev before actually doing the renames. Assuming that this renaming will be a close follow-up I do not have a particular opinion about the current name chosen, but maybe it is useful to actually start this discussion now to avoid renaming this class in particular again.

Thanks Thomas.

I would prefer G1SegmentedArrayFreePool here, seeing the segmented array as the important thing (I understand that G1SegmentedArrayBufferListFreePool is too long).

Sure.

I think there is already a CR to reconsider naming of all these classes,

Do you mean https://bugs.openjdk.java.net/browse/JDK-8276299 or some other issue?

maybe add G1SegmentedArrayBufferList to the ones that need renaming;

If you mean 8276299 above, sure I will add this to the renaming list of 8276299.

in particular I think right now that the "BufferList" of G1SegmentedArrayBufferList is kind of redundant.

Not quite get your point, would you mind to clarify further?

Sorry for not speaking up earlier about this, but it only came to my mind right now.

It's OK, it's never late to make necessary changes. :)

It would be great for that renaming CR to start a thread in hotspot-gc-dev before actually doing the renames.

Do you mean not send a pr but just send email to hotspot-gc-dev to discuss this idea of renaming?

Assuming that this renaming will be a close follow-up I do not have a particular opinion about the current name chosen, but maybe it is useful to actually start this discussion now to avoid renaming this class in particular again.

If you mean 8276299 above, then I think these 2 (8276299 and this one) are not quite related to each other, 8276299 is to unify the naming of "buffer", "node" and "element" (especially in card set area currently), but this one is to factor out Factor out G1CardSetFreePool and enable evac failure to reuse the freeing memory logic in current G1CardSetFreePool.
Sure, I will start a discussion for 8276299 before actually send the pr.

Thanks Thomas.

I would prefer G1SegmentedArrayFreePool here, seeing the segmented array as the important thing (I understand that G1SegmentedArrayBufferListFreePool is too long).

Sure.

I think there is already a CR to reconsider naming of all these classes,

Do you mean https://bugs.openjdk.java.net/browse/JDK-8276299 or some other issue?

Yes.

maybe add G1SegmentedArrayBufferList to the ones that need renaming;

If you mean 8276299 above, sure I will add this to the renaming list of 8276299.

in particular I think right now that the "BufferList" of G1SegmentedArrayBufferList is kind of redundant.

Not quite get your point, would you mind to clarify further?

A segmented array is an array consisting of segments (as opposed to a single huge array of something); a list of buffers, where a "buffer" is nothing but an array (of some element type) is almost the same. One is a set of chunks of elements (to explicitly use other words), the other too.

It would be great for that renaming CR to start a thread in hotspot-gc-dev before actually doing the renames.

Do you mean not send a pr but just send email to hotspot-gc-dev to discuss this idea of renaming?

Not to discuss the idea of renaming, 8276299 is pretty clear about that, but discuss the actual mappings from old name to new name. Maybe this will wake up more people to the discussion than hiding it in a PR :)

Assuming that this renaming will be a close follow-up I do not have a particular opinion about the current name chosen, but maybe it is useful to actually start this discussion now to avoid renaming this class in particular again.

If you mean 8276299 above, then I think these 2 (8276299 and this one) are not quite related to each other, 8276299 is to unify the naming of "buffer", "node" and "element" (especially in card set area currently), but this one is to factor out Factor out G1CardSetFreePool and enable evac failure to reuse the freeing memory logic in current G1CardSetFreePool. Sure, I will start a discussion for 8276299 before actually send the pr.

That's true, but we are renaming something that also contains a "Buffer" in it and seemingly related.

So instead of renaming this G1BufferListFreePool again to something else in 8276299, maybe we could save the time and immediately change it to the final name now, then in 8276299 do the same for the other classes.

Then 8276299 will hopefully go through more smoothly too if we already decided on the new names beforehand as well.

Thanks for clarification, I see your point, will initiate an discussion later. :)

Discussion thread is here: https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2021-November/037626.html

Per above discussion, we prefer to use following naming relationship:

segmented array (1) -- segment (N) -- slot (M) -- element (1)

Hamlin-Li · 2021-11-22T03:32:30Z

kindly reminder ~

albertnetymk · 2021-11-22T09:41:01Z

I think splitting "move" and "rename" into two PRs (the current commits history is a bit hard to follow) will make the review process much easier and the included meaningful changes more discernible.

tschatzl · 2021-11-22T09:30:40Z

src/hotspot/share/gc/g1/g1CardSetMemory.hpp

@@ -25,9 +25,9 @@
 #ifndef SHARE_GC_G1_G1CARDSETMEMORY_HPP
 #define SHARE_GC_G1_G1CARDSETMEMORY_HPP

+#include "gc/g1/g1SegmentedArrayFreePool.hpp"
