[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