[9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

[Vladimir Ivanov]

Paul, Peter, Morris, thanks for review.

Best regards,
Vladimir Ivanov

On 9/5/14, 3:51 PM, Paul Sandoz wrote:
>
> On Sep 5, 2014, at 1:25 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>> Paul, thanks for review.
>>
>>> Generally looks good (re: Peter's observation of continue/break).
>>>
>>> - LambdaFormEditor
>>>
>>>    61     private static final class Transform {
>>>    62         final long packedBytes;
>>>    63         final byte[] fullBytes;
>>>    64         final LambdaForm result;  // result of transform, or null, if there is none available
>>>    65
>>>    66         private enum Kind {
>>>
>>> More an oddity really, Transform.Kind is private but exposed via package private methods.
>> Good point. I'll fix that.
>>
>
> +1 on review.
>
>
>>>
>>>   187         static Transform of(Kind k, int b1, byte[] b234) {
>>>
>>>
>>> It might be worthwhile investing in a unit test for LambdaFormEditor to exercise the transform types and transitions, otherwise edge cases might bite us later.
>> Tests for JEP 210 (SQE is working on them) should cover that.
>>
>
> Ok.
>
>
>>> I was thinking Transform could be greatly simplified if one just uses byte[], but IIUC (via JOL) that increases the instance size by 16 bytes, although that may be small compared to the LambdaForm result and if say a WekRef is also used to hold that result. Plus if that is the case the transformCache could be simplified by just supporting Transform[] and ConcurrentHashMap. I guess the underlying question i am asking here is do these space savings really give us much over some less complicated code?
>> All these specializations can be considered overoptimizations, but I'd prefer to leave them. Complexity is manageable, encapsulated, and localized ([1],[2]).
>>
>
>> And these specializations are for the common case. The numbers I got for Octane shows that:
>>   (1) large transforms are very rare:
>> 	98-99% of Transforms fit into packed representation;
>>   (2) for LF caches
>>       (a) 70-80% are single-element;
>>       (b) 20-30% fit into array (<16 elements)
>>       (c) CHM is needed very rarely (<<1%)
>>
>
> OK, good to see some numbers on this, quite reassuring.
>
> Paul.
>