RFR: 8342001: GenShen: Factor cases for allocation type into separate methods [v2]

[Y. Srinivas Ramakrishna]

On Mon, 14 Oct 2024 22:11:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 762:
>> 
>>> 760: 
>>> 761: HeapWord* ShenandoahFreeSet::allocate_for_mutator(ShenandoahAllocRequest &req, bool &in_new_region) {
>>> 762:   maybe_change_allocation_bias();
>> 
>> Why update alloc bias if allocation is doomed to fail at next line? Is that the intention? If not, may be do the bias update only when there is chance for success in the allocation? See suggestions further below.
>
> I had this same thought, but ended on the side of preserving existing behavior. @kdnilsen , should we not update the allocation bias if we can detect an early allocation failure?

ok

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 799:
>> 
>>> 797:                                 - _partitions.rightmost_empty(ShenandoahFreeSetPartitionId::Mutator));
>>> 798:     _partitions.set_bias_from_left_to_right(ShenandoahFreeSetPartitionId::Mutator, (non_empty_on_right < non_empty_on_left));
>>> 799:     _alloc_bias_weight = _InitialAllocBiasWeight;
>> 
>> The value of 256 for `_InitialAllocBiasWeight` seems a bit of magic. How was it chosen, and is it subject to bit-rot with code evolving? I can imagine that the bias update at a higher frequency is apt to not matter much, and since the leftmost and rightmost empty calculation is not free, so larger values are favored.
>> 
>> Also should we use the more usual `static const ssize_t INITIAL_ALLOC_BIAS_WEIGHT` Hotspot style for constants, rather than the camel case with an initial underscore (which seems not common)?
>
> I'm not sure where the initial value comes from. I will change to the idiomatic name convention.

ok

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/511#discussion_r1801672424
PR Review Comment: https://git.openjdk.org/shenandoah/pull/511#discussion_r1801672577