RFR: leverage profiling for tableswitch/lookup switch

[Roland Westrelin]

> *) 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.

> *) gcm.cpp, comment is outdated:
>  1870     // Divide the frequency between all successors evenly

Right.

> *) 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.

Roland.