RFR: 8253402: Convert vmSymbols::SID to enum class [v2]

Ioi Lam iklam at openjdk.java.net
Sat Oct 10 07:17:12 UTC 2020


On Sun, 27 Sep 2020 11:09:30 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes
>> the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last
>> revision:
>>  - more vmEnums.hpp fixes; fixed minimal VM build
>>  - Merge branch 'master' into 8253402-convert-vmsymbols-sid-to-enum-class
>>  - Moved forward declaration of vmSymbolID to vmEnums.hpp
>>  - clean up whitespaces and removed useless comment
>>  - removed unnecessary include
>>  - 8253402: Convert vmSymbols::SID to enum class
>
> src/hotspot/share/utilities/enumIterator.hpp line 1:
> 
>> 1: /*
> 
> I think there are problems with this EnumIterator class. It was based in part on a prototype of mine, which I've been
> revisiting and revising, because I think it has problems. That prototype, in turn, was based on the existing
> WeakProcessorPhases::Iterator, which I think has some of the same failings. And I think this version expands on some of
> those problems. I don't yet have a full review, but below are some observations and issues.  I'm working on an
> alternative.  A fundamental question is what style of "iterator" do we want.  (1) One style is self-contained; you
> create a single iterator which knows both the current position and the iteration limit, and step until a predicate
> (is_end() in the current code) is true.  (2) Another style is to have a pair of iterators, one designating the current
> position and the other designating the iteration limit.  This is the style used by the C++ Standard Library.
> Both my earlier prototype and the EnumIterator in this PR are 1-style but attempt (not necessarily very well, in my
> opinion) to also provide 2-style behavior. The point of that currently seems to be to support the new "range-based for"
> feature. (Said feature is currently not in the permitted list according to the Style Guide. I intentionally left it out
> because I think its utility is pretty strongly dependent on adopting 2-style iterators, which is not very well
> motivated without using the Standard Library.)  One requirement for an enum iterator (for me) is that it doesn't
> require a "fake" enumerator that designates the exclusive end of the range.  The current proposal fails that test.  A
> problem with all of the variants is that they are trying to be both 1-style (providing is_end) and 2-style (providing
> being/end), with the result that they do neither well. This is especially true for the variant in the PR. I think part
> of the problem is that the begin/end functions don't belong to the iterator class; they should be part of a separate
> range class.  Aside: I think it is possible to provide iteration that doesn't assume sequential enumerators if one is
> willing to have some code duplication or has an enum that is x-macro based. While possibly an interesting exercise, I
> doubt that's worth pursuing. Just mentioning it in case anyone thinks this would actually useful.  I'm not certain how
> to proceed. Maybe this should be moved elsewhere as not yet ready to be a widely used "utility"? Or maybe go ahead with
> it with the intention of improving it?

Hi Kim, I have integrated the 2-style enumerator that you sent me off-line. Usage info (see enumIterator.hpp for
details).

// Example (see vmSymbols.hpp/cpp)
//
// ENUMERATOR_RANGE(vmSymbolID, vmSymbolID::FIRST_SID, vmSymbolID::LAST_SID)
// constexpr EnumRange<vmSymbolID> vmSymbolsRange;
// using vmSymbolsIterator = EnumIterator<vmSymbolID>;
//
// /* Without range-based for, allowed */
// for (vmSymbolsIterator it = vmSymbolsRange.begin(); it != vmSymbolsRange.end(); ++it) {
//  vmSymbolID index = *it; ....
// }
//
// /* With range-base for, not allowed by HotSpot coding style yet */
// for (vmSymbolID index : vmSymbolsRange) {
//    ....
// }

I have rewritten all the iteration loops using the "Without range-based for" style. We can change to the "With
range-base for" style when the HotSpot Coding Style Guide allows it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/276


More information about the hotspot-dev mailing list