RFR: 8055702 - Remove the generations array
Kim Barrett
kim.barrett at oracle.com
Thu Oct 16 21:39:42 UTC 2014
On Oct 14, 2014, at 9:28 AM, Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com> wrote:
>
> Hi all,
>
> Resurrecting this thread from the past.
> I got one review from Mikael, need another to clean this up.
>
> Thanks!
> /Jesper
>
>
> Jesper Wilhelmsson skrev 22/8/14 15:20:
>> […]
>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8055702/webrev/
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8055702
==============================================================================
agent/src/share/classes/sun/jvm/hotspot/memory/GenCollectedHeap.java
77 if ((i < 0) || (i >= nGens())) {
78 return null;
79 }
80
81 if (i == 0) {
82 return genFactory.newObject(youngGenField.getAddress());
83 } else {
84 return genFactory.newObject(oldGenField.getAddress());
85 }
Most of the java code seems to still be agnostic about the number of
generations. This is the one place where the limit of 2 generations
is being hard-wired. I think it would be appropriate to protect this
code with some sort of check that nGens() < 2.
Optionally, I think it would now be simpler to merge the two if
statements into a single switch statement, e.g.
switch (i) {
case 0:
return genFactory.newObject(youngGenfield.getAddress());
case 1:
return genFactory.newObject(oldGenfield.getAddress());
default:
// no generation for i, and assertions disabled.
return null;
}
[Of course, leave the line 72-75 assertion in place.]
==============================================================================
src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
957 prev_size = prev_gen->capacity();
958 gclog_or_tty->print_cr(" Younger gen size "SIZE_FORMAT,
959 prev_size/1000);
The logging statement at 958 appears to be mis-indented.
[Pre-existing problem.]
==============================================================================
src/share/vm/memory/genCollectedHeap.cpp
141 ReservedSpace young_rs = heap_rs.first_part(_gen_specs[0]->max_size(), false, false);
142 _young_gen = _gen_specs[0]->init(young_rs, 0, rem_set());
143 heap_rs = heap_rs.last_part(_gen_specs[0]->max_size());
144
145 ReservedSpace old_rs = heap_rs.first_part(_gen_specs[1]->max_size(), false, false);
146 _old_gen = _gen_specs[1]->init(old_rs, 1, rem_set());
147 heap_rs = heap_rs.last_part(_gen_specs[1]->max_size());
Could we have a helper function for this near duplicated code?
There's a bunch of hard-coded 0s and 1s here for young and old
respectively.
This also makes me wonder if _gen_specs[] should also be eliminated;
it looks like it was a parallel array to the _gens[] array, with the
latter being no longer present.
234 void GenCollectedHeap::save_used_regions(int level) {
235 assert(level < _n_gens, "Illegal level parameter");
236 if (level == 1) {
237 _old_gen->save_used_region();
238 }
239 _young_gen->save_used_region();
240 }
More hard-coded 0s (implicit) and 1s here for young and old
respectively.
I looked at the changes to do_collection() involved in factoring out
new collect_generation(). I *think* they are ok, but it's hard to be
sure because the webrev diffs are a bit of a mess. It might be easier
to review if collect_generation() followed do_collection() rather than
preceeding it. [Of course, making that change would make a mess of an
incremental webrev.]
==============================================================================
src/share/vm/memory/genCollectedHeap.hpp
373 Generation* prev_gen(Generation* gen) const {
374 int l = gen->level();
375 guarantee(l == 1, "Out of bounds");
376 return _young_gen;
377 }
378
379 // Return the generation after "gen".
380 Generation* next_gen(Generation* gen) const {
381 int l = gen->level() + 1;
382 guarantee(l == 1, "Out of bounds");
383 return _old_gen;
384 }
385
386 Generation* get_gen(int i) const {
387 guarantee(i >= 0 && i < _n_gens, "Out of bounds");
388 if (i == 0) return _young_gen;
389 else return _old_gen;
390 }
Suggest changing next_gen() to
Generation* next_gen(Generation* gen) const {
int l = gen->level();
guarantee(l == 0, "Out of bounds");
return _old_gen;
}
to eliminate the +1 and be more consistent with prev_gen().
Oh, but maybe this doesn't matter. I just re-read the webrev request
and see that get_gen(), next_gen(), and prev_gen() are slated to go
away.
Again here, many hard-coded 0s and 1s for young and old respectively.
BTW, "l" (lowercase L) and "1" (integer one) look *very* similarly in
some fonts, making "l" (lowercase L) a poor choice of variable name.
I had to look really closely at the webrev to see that "l == 1" was
not tautological. Similar issue with "O" (capital o) and 0 (integer
zero).
==============================================================================
src/share/vm/memory/genMarkSweep.cpp
161 // Scratch request on behalf of oldest generation; will do no
162 // allocation.
163 ScratchBlock* scratch = gch->gather_scratch(gch->get_gen(gch->_n_gens-1), 0);
Why not "gch->old_gen()" instead of "gch->get_gen(gch->_n_gens-1)" ?
==============================================================================
src/share/vm/memory/generation.cpp
162 Generation* Generation::next_gen() const {
163 GenCollectedHeap* gch = GenCollectedHeap::heap();
164 int next = level() + 1;
165 if (next < gch->_n_gens) {
166 return gch->get_gen(next);
167 } else {
168 return NULL;
169 }
170 }
Perhaps instead
Generation* Generation::next_gen() const {
GenCollectedHeap* gch = GenCollectedHeap::heap();
if (this == gch->young_gen()) {
return gch->old_gen();
} else {
assert(this == gch->old_gen());
return NULL;
}
}
But again here, maybe this next_gen() is also slated to go away?
==============================================================================
src/share/vm/runtime/vmStructs.cpp
547 static_field(GenCollectedHeap, _gch, GenCollectedHeap*) \
548 nonstatic_field(GenCollectedHeap, _n_gens, int) \
These two lines appear to be incorrectly indented wrto the surrounding
parts of this file.
==============================================================================
More information about the hotspot-gc-dev
mailing list