RFR (M): 8077144: Concurrent mark initialization takes too long

[Kim Barrett]

> On Mar 29, 2016, at 5:06 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi,
> 
> On Fri, 2016-03-25 at 21:48 -0400, Kim Barrett wrote:
>>> On Mar 25, 2016, at 9:38 PM, Kim Barrett <kim.barrett at oracle.com>
>>> wrote:
>>> 
>>>> On Mar 15, 2016, at 6:12 PM, Thomas Schatzl <
>>>> thomas.schatzl at oracle.com> wrote:
>>>> 
>>>> Hi Mikael,
>>>> 
>>>> updated webrev at
>>>> http://cr.openjdk.java.net/~tschatzl/8077144/webrev.3/ (full)
>>>> http://cr.openjdk.java.net/~tschatzl/8077144/webrev.2_to_3/ (diff
>>>> )
>>>> 
>>>> which implements the suggested changes.
>>> 
>>> src/share/vm/utilities/bitMap.hpp
>>> 147   static idx_t size_in_words(size_t size_in_bits) {
>>> 
>>> I find the name of this function confusing in conjunction with the
>>> no-arg ordinary member function; I'm not keen on overloads with
>>> with
>>> very different semantics and usage. Clearer (to me) here might be
>>> something like calc_size_in_words.
>> 
>> The existing BitMap::word_align_up could be used instead of
>> introducing this new function.
> 
>  I am not sure if that function helps in an as concise way as
> calc_size_in_words().
> 
> I.e. do you suggest to use word_align_up(size())? Then I could as well
> use size_in_bytes() and divide by sizeof(bm_word_t). (by other
> alignment/size constraints a per-region part must always be word
> -aligned).
> 
> There has been a particular (non-public) request to be specific with
> sizes in these changes.
> 
> Or do you mean, use word_align_up() in calc_size_in_words()?

When I mentioned word_align_up, I was thinking there was a bits per bm_word_t
constant somewhere that could be used to get the word size after aligning up.
But there doesn’t seem to be any such thing, so ignore that part of the suggestion.

So I would like a different name, rather than overloading size_in_words.
calc_size_in_words would be fine, or something else if you have a better suggestion.

Other than this, with the deferral of other issues to JDK-8151386, looks good.
I don’t need a new webrev for a name change here.