RFR: leverage profiling for tableswitch/lookup switch

[Aleksey Shipilev]

On 01/12/2018 05:05 PM, Roland Westrelin wrote:
> 
>> *) Maybe we should guard the feature with "chicken" diagnostic flag, like
>> ShenandoahTableSwitchProfiling? This would also mark the paths we would need to remove/refresh once
>> the change trickles down from upstream.
> 
> Sure but would you want all code paths that were changed to be guarded
> by a new flag? That sounds a bit overkill to me.

I guess the entry in LIRGenerator::do_TableSwitch, LIRGenerator::do_LookupSwitch and
Parse::create_jump_tables would be enough?


>> *) parse2.cpp, this one is just table[3*j + 0], etc:
>>
>>  498       table[j+j+j+0] = iter().get_int_table(2+j+j);
>>  499       table[j+j+j+1] = iter().get_dest_table(2+j+j+1);
>>  500       table[j+j+j+2] = profile == NULL ? 1 : profile->count_at(j);
>>
>>  527     jint match_int   = table[j+j+j+0];
>>  528     int  dest        = table[j+j+j+1];
>>  529     int  cnt         = table[j+j+j+2];
> 
> The original code insists on using j+j instead of 2*j, I suppose because
> it emphasizes that each element is really a different field or something
> like that. I followed along. Anyway I can change it if you like.

This looks like a plain Array-of-Structs, and the usual idiom is len*sIndex + off, so yeah, "j+j+j"
looks very odd. I suspect "j+j" was the attempt at microoptimization? I would guess upstream would
suggest the same change.

Thanks,
-Aleksey