Getting back into indy...need a better argument collector!

Charles Oliver Nutter headius at headius.com
Fri Mar 26 00:39:28 UTC 2021


Well it only took me five years to circle back to this but I can
confirm it is just as bad now as it ever was. And it is definitely due
to collecting a single type.

I will provide whatever folks need to investigate but it is pretty
straightforward. When asking for asCollector of a non-Object[] type,
the implementation will first gather arguments into an Object[], and
then create a copy of that array as the correct type. So two arrays
are created, values are copied twice.

I can see this quite clearly in the assembly after letting things
optimize. A new Object[] is created and populated, and then a second
array of the correct type is created followed by an arraycopy
operation.

I am once again backing off using asCollector directly to instead
provide my own array-construction collector.

Should be easy to reproduce the perf issues simply by doing an
asCollector that results in some subtype of Object[].

On Thu, Jan 14, 2016 at 8:18 PM Charles Oliver Nutter
<headius at headius.com> wrote:
>
> Thanks Duncan. I will try to look under the covers this evening.
>
> - Charlie (mobile)
>
> On Jan 14, 2016 14:39, "MacGregor, Duncan (GE Energy Management)" <duncan.macgregor at ge.com> wrote:
>>
>> On 11/01/2016, 11:27, "mlvm-dev on behalf of MacGregor, Duncan (GE Energy
>> Management)" <mlvm-dev-bounces at openjdk.java.net on behalf of
>> duncan.macgregor at ge.com> wrote:
>>
>> >On 11/01/2016, 03:16, "mlvm-dev on behalf of Charles Oliver Nutter"
>> ><mlvm-dev-bounces at openjdk.java.net on behalf of headius at headius.com>
>> >wrote:
>> >...
>> >>With asCollector: 16-17s per iteration
>> >>
>> >>With hand-written array construction: 7-8s per iteration
>> >>
>> >>A sampling profile only shows my Ruby code as the top items, and an
>> >>allocation trace shows Object[] as the number one object being
>> >>created...not IRubyObject[]. Could that be the reason it's slower?
>> >>Some type trickery messing with optimization?
>> >>
>> >>This is very unfortunate because there's no other general-purpose way
>> >>to collect arguments in a handle chain.
>> >
>> >I haven¹t done any comparative benchmarks in that area for a while, but
>> >collecting a single argument is a pretty common pattern in the Magik code,
>> >and I had not seen any substantial difference when we last touched that
>> >area. However we are collecting to plain Object[] so it might be that is
>> >the reason for the difference. If I¹ve got time later this week I¹ll do
>> >some experimenting and check what the current situation is.
>>
>> Okay, I’ve now had a chance to try this in with our language benchmarks
>> and can’t see any significant difference between a hand crafted method and
>> asCOllector, but we are dealing with Object and Object[], so it might be
>> something to do with additional casting.
>>
>> Duncan.
>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


More information about the mlvm-dev mailing list