RFR: 8371667: Shenandoah: Re-design alloc request type enum for better efficiency and cleaner code

[Xiaolong Peng]

On Wed, 12 Nov 2025 09:54:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Honestly, I don't believe switching from explicit switch cases to bit manipulation is that much readable here. If you want to pursue this, then maybe do the proper bitmask manipulation, something like:
> 
> ```
>  // bit 0: mutator (0) or GC (1) alloc 
>  // bit 1: LAB (0) or shared (1) alloc 
>  // bit 2: if LAB, then GCLAB (0) or PLAB (1)
>  // bit 3: if mutator, then normal (0) or CDS (1)
>  typedef int AllocType;
> 
>  constexpr int bit_gc_alloc = 1 << 1;
>  constexpr int bit_lab_alloc = 1 << 2;
>  constexpr int bit_plab_alloc = 1 << 3;
>  constexpr int bit_cds_alloc = 1 << 4;
>  ...
>  const bool is_lab_alloc(AllocType type) {
>     return (type & bit_lab_alloc) != 0;
>  }
>  
>  constexpr AllocType _alloc_tlab = bit_lab_alloc;
>  constexpr AllocType _alloc_plab = bit_gc_alloc | bit_lab_alloc | bit_plab_alloc;
>  ...
> ```
> 
> Remains to be seen what is the most sensible encoding scheme here.

Thanks you for the suggestion.

I didn't think about changing the enum to constexpr int for alloc request type, just wanted to re-shuffle the values of current enum, so I only used bit manipulation when test if it lab allocation. I'll update the PR and use proper bitmask manipulation as you suggested.

In terms of readability, explicit switch cases is definitely more readable, but machine code size will be also larger with more branches, so in theory it is less efficient.

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

PR Comment: https://git.openjdk.org/jdk/pull/28247#issuecomment-3522696592