On Wed, 4 Sep 2024 14:18:09 GMT, Claes Redestad wrote:
>>> LGTM
>>>
>>> AFAICT before this we'd only call `DirectCodeBuilder::labelToBci` once per
>>> label, but now we'll do so roughly `2*n*log(n) + n` times. I would assume
>>> getting rid of the `TreeMap` and `Integer` key allocations more t
On Wed, 4 Sep 2024 15:27:40 GMT, Chen Liang wrote:
> > I'll see if I can get the benchmarks in
> > `test/micro/org/openjdk/bench/jdk/classfile` working. It looks like there
> > may be one or more of them which would reach into this code.
>
> Just checked; no benchmark is currently supplying a
On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd wrote:
>> Please review this change, which reduces the number of allocations in
>> `StackMapDecoder::writeFrames` by using a sorted array instead of a
>> `TreeMap` to sort and uniquify entries before writing. It also
>> adds a validation missed b
On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd wrote:
>> Please review this change, which reduces the number of allocations in
>> `StackMapDecoder::writeFrames` by using a sorted array instead of a
>> `TreeMap` to sort and uniquify entries before writing. It also
>> adds a validation missed b
On Wed, 4 Sep 2024 14:59:50 GMT, David M. Lloyd wrote:
> I'll see if I can get the benchmarks in
> `test/micro/org/openjdk/bench/jdk/classfile` working. It looks like there may
> be one or more of them which would reach into this code.
Just checked; no benchmark is currently supplying a manual
On Wed, 4 Sep 2024 14:18:09 GMT, Claes Redestad wrote:
> > If so, then this amounts to a fairly minimal and direct code path, thus I
> > approached this as being an "obvious" (as opposed to theoretical)
> > improvement.
>
> I agree that it looks like the typical path is trivial, but I don't ha
On Wed, 4 Sep 2024 14:12:06 GMT, David M. Lloyd wrote:
>> LGTM
>>
>> AFAICT before this we'd only call `DirectCodeBuilder::labelToBci` once per
>> label, but now we'll do so roughly `2*n*log(n) + n` times. I would assume
>> getting rid of the `TreeMap` and `Integer` key allocations more than m
On Wed, 4 Sep 2024 14:12:06 GMT, David M. Lloyd wrote:
> If so, then this amounts to a fairly minimal and direct code path, thus I
> approached this as being an "obvious" (as opposed to theoretical) improvement.
I agree that it looks like the typical path is trivial, but I don't have the
full
On Wed, 4 Sep 2024 13:08:49 GMT, Claes Redestad wrote:
> LGTM
>
> AFAICT before this we'd only call `DirectCodeBuilder::labelToBci` once per
> label, but now we'll do so roughly `2*n*log(n) + n` times. I would assume
> getting rid of the `TreeMap` and `Integer` key allocations more than makes
On Wed, 4 Sep 2024 01:06:10 GMT, Shaojin Wen wrote:
> It looks good, but can you provide the codeSize before and after the change?
> For example, add the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions
> -XX:+PrintInlining` to find `writeFrames` and see if this PR will change from
> les
On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd wrote:
>> Please review this change, which reduces the number of allocations in
>> `StackMapDecoder::writeFrames` by using a sorted array instead of a
>> `TreeMap` to sort and uniquify entries before writing. It also
>> adds a validation missed b
On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd wrote:
>> Please review this change, which reduces the number of allocations in
>> `StackMapDecoder::writeFrames` by using a sorted array instead of a
>> `TreeMap` to sort and uniquify entries before writing. It also
>> adds a validation missed b
On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd wrote:
>> Please review this change, which reduces the number of allocations in
>> `StackMapDecoder::writeFrames` by using a sorted array instead of a
>> `TreeMap` to sort and uniquify entries before writing. It also
>> adds a validation missed b
On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd wrote:
>> Please review this change, which reduces the number of allocations in
>> `StackMapDecoder::writeFrames` by using a sorted array instead of a
>> `TreeMap` to sort and uniquify entries before writing. It also
>> adds a validation missed b
On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd wrote:
>> Please review this change, which reduces the number of allocations in
>> `StackMapDecoder::writeFrames` by using a sorted array instead of a
>> `TreeMap` to sort and uniquify entries before writing. It also
>> adds a validation missed b
> Please review this change, which reduces the number of allocations in
> `StackMapDecoder::writeFrames` by using a sorted array instead of a
> `TreeMap` to sort and uniquify entries before writing. It also
> adds a validation missed by the original implementation.
>
> Tested using `StackMapsTe
On Tue, 3 Sep 2024 16:13:39 GMT, David M. Lloyd wrote:
> Please review this change, which reduces the number of allocations in
> `StackMapDecoder::writeFrames` by using a sorted array instead of a
> `TreeMap` to sort and uniquify entries before writing.
>
> Tested using `StackMapsTest`.
I thi
On Tue, 3 Sep 2024 16:13:39 GMT, David M. Lloyd wrote:
> Please review this change, which reduces the number of allocations in
> `StackMapDecoder::writeFrames` by using a sorted array instead of a
> `TreeMap` to sort and uniquify entries before writing.
>
> Tested using `StackMapsTest`.
The p
On Tue, 3 Sep 2024 16:13:39 GMT, David M. Lloyd wrote:
> Please review this change, which reduces the number of allocations in
> `StackMapDecoder::writeFrames` by using a sorted array instead of a
> `TreeMap` to sort and uniquify entries before writing.
>
> Tested using `StackMapsTest`.
Since
Please review this change, which reduces the number of allocations in
`StackMapDecoder::writeFrames` by using a sorted array instead of a
`TreeMap` to sort and uniquify entries before writing.
Tested using `StackMapsTest`.
-
Commit messages:
- 8339492: StackMapDecoder::writeFrames
20 matches
Mail list logo
