[lworld] RFR: 8263067: [lworld] Improve buffer instance allocation in MacroAssembler::store_inline_type_fields_to_buf
Yi Yang
github.com+5010047+kelthuzadx at openjdk.java.net
Mon Mar 8 04:44:18 UTC 2021
On Fri, 5 Mar 2021 08:06:52 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:
>> Hi Tobias,
>>
>> I think it's reasonable. We can create such a buffered instance similar to `MacroAssembler::allocate_instance` or just using it. What do you think? If you think it's a feasible way, I can also try to tweak the implementation, keeping using the same buffer allocation mechanism on aarch64.
>>
>> Thanks!
>> Yang
>
> Yes, I think it would be nice to factor the common code out of `MacroAssembler::allocate_instance` (we don't need the zeroing and some of the checks) and use it for buffer allocation.
Now it will try to allocate a new buffered inline instance either from TLAB or eden space. I tried to build and change its counterpart on aarch64 but failed. Fixing these errors may conflict with #353, so I keep it unchanged until #353 merged.
I've noticed a [FIXME comment](https://github.com/openjdk/valhalla/pull/362/files#diff-5d34d63ceb6d72dd9124399b7628bf498b4dec22ea5c5edc0426e80ee6e3bae4R5456) that hope to inline buffer packing in place, it would reduce a call instruction and do all stuff(buffer allocation+packing) in fastpath, but on the other hand, it increases the compiled code size and the final code may be duplicated with pack handler in SharedRuntime::generate_buffered_inline_type_adapter. I'm not sure which is more attractive to us, or keep it unchanged? Looking forward to your inputs.
Thanks!
Yang
-------------
PR: https://git.openjdk.java.net/valhalla/pull/362
More information about the valhalla-dev
mailing list