early steps on the road to customization

[Peter Levart]

Hi,

I just wanted to see how far I could go with existing VM features, 
namely: @Stable annotation and MutableCallSite. Here's a variant of 
ClassValue that replaces entirely existing one and supports dynamic 
sizing of backing array, get(), remove() and put() operations and even 
re-use of table indexes used by GC-ed ClassValue instances. It passes 
the ClassValueTest:

https://github.com/plevart/valhalla/pull/3

It still manages to constant-fold the associated value when both 
ClassValue and Class are constants. Here's a benchmark that also 
includes variants where either or both of ClassValue and Class are 
constants or not to show how it compares with existing ClassValue. It is 
slower, but not by very much:

https://gist.github.com/plevart/edce6f150b881b542cc722ce11424ae3

I hope this can be used in performance experiments until JVM support for 
speculative values is created.

Regards, Peter

On 8/29/20 12:12 AM, John Rose wrote:
> Very tasty, thank you!
>
> Here’s a discussion of the issue with CV::remove:
>
> https://bugs.openjdk.java.net/browse/JDK-8238260
>
> On Aug 28, 2020, at 5:53 AM, Peter Levart <peter.levart at gmail.com> wrote:
>> Hi,
>>
>> On 8/27/20 11:52 PM, John Rose wrote:
>>> The effects of each factor can be estimated by appropriate experiments:
>>>
>>> - use a ClassValue approximator that the JIT can constant-fold
>> ...here's a quick hack that makes the 1st N (32) evaluated ClassValue instances constant-foldable:
>>
>> https://github.com/plevart/valhalla/pull/1
>>
>> I haven't checked the JIT-ed code, but JMH benchmark undoubtedly shows that it works:
>>
>> https://gist.github.com/plevart/3ddada53824faede66e843acd0dfa92f
>>
>> This patch does not support ClassValue.remove operation. Interesting question is whether it would be possible to support remove via some kind of MethodHandle/de-opt trickery (Rémi would know).
>>
>> Regards, Peter
>>