On Wed, 25 May 2022 14:13:52 GMT, Claes Redestad wrote:
>> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey`
>> allows keys to be compacted when all byte values of the key fit in 4 bits,
>> otherwise a byte array is allocated and used. This means that all transforms
>> wi
> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey`
> allows keys to be compacted when all byte values of the key fit in 4 bits,
> otherwise a byte array is allocated and used. This means that all transforms
> with a kind value above 15 will be forced to allocate and use ar
On Wed, 25 May 2022 14:13:52 GMT, Claes Redestad wrote:
>> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey`
>> allows keys to be compacted when all byte values of the key fit in 4 bits,
>> otherwise a byte array is allocated and used. This means that all transforms
>> wi
On Wed, 25 May 2022 14:03:41 GMT, Claes Redestad wrote:
>> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey`
>> allows keys to be compacted when all byte values of the key fit in 4 bits,
>> otherwise a byte array is allocated and used. This means that all transforms
>> wi
> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey`
> allows keys to be compacted when all byte values of the key fit in 4 bits,
> otherwise a byte array is allocated and used. This means that all transforms
> with a kind value above 15 will be forced to allocate and use ar
> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey`
> allows keys to be compacted when all byte values of the key fit in 4 bits,
> otherwise a byte array is allocated and used. This means that all transforms
> with a kind value above 15 will be forced to allocate and use ar
On Wed, 25 May 2022 13:37:14 GMT, Claes Redestad wrote:
>> Maybe an `assert b == b23456[i]` would be nice here.
>
> All usage implies the int is an argument position, which by spec is
> constrained to be in the 0-255 range. But surely checking or asserting
> shouldn't hurt.
Yes, please. IMHO i
On Wed, 25 May 2022 13:30:23 GMT, Jorn Vernee wrote:
>> Maybe not... argument positions should fit in a byte as well. But, maybe
>> there are other problematic cases? Or are the ints guaranteed to fit in a
>> byte?
>
> Maybe an `assert b == b23456[i]` would be nice here.
All usage implies the
On Wed, 25 May 2022 13:27:17 GMT, Jorn Vernee wrote:
>> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey`
>> allows keys to be compacted when all byte values of the key fit in 4 bits,
>> otherwise a byte array is allocated and used. This means that all transforms
>> with
On Wed, 25 May 2022 13:28:52 GMT, Jorn Vernee wrote:
>> src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 239:
>>
>>> 237: for (int i = 0; i < b23456.length; i++) {
>>> 238: int b = b23456[i] & 0xFF;
>>> 239: bitset |= b;
>>
>> L
On Wed, 25 May 2022 09:38:08 GMT, Claes Redestad wrote:
> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey`
> allows keys to be compacted when all byte values of the key fit in 4 bits,
> otherwise a byte array is allocated and used. This means that all transforms
> with a
On Wed, 25 May 2022 09:38:08 GMT, Claes Redestad wrote:
> The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey`
> allows keys to be compacted when all byte values of the key fit in 4 bits,
> otherwise a byte array is allocated and used. This means that all transforms
> with a
The bespoke caching scheme in `jl.invoke.LambdaFormEditor.TransformKey` allows
keys to be compacted when all byte values of the key fit in 4 bits, otherwise a
byte array is allocated and used. This means that all transforms with a kind
value above 15 will be forced to allocate and use array comp
13 matches
Mail list logo
