RFR: 8331658: secondary_super_cache does not scale well: C1 [v2]
Andrew Haley
aph at openjdk.org
Tue Jun 4 09:03:17 UTC 2024
On Mon, 3 Jun 2024 19:41:49 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:
> It's unfortunate to see C1-specific version of secondary supers table lookup. Why don't you reuse `MacroAssembler::lookup_secondary_supers_table` instead?
It's a complicated tradeoff. In particular, `lookup_secondary_supers_table` needs to use fixed registers, and quite a lot of them. This patch is a version of the table lookup that uses as few registers as possible, and none of them are fixed.
C1 has its own runtime logic partly because of the vagaries of its register allocation strategy, and while `MacroAssembler::lookup_secondary_supers_table` would work here, it would generate more code and work less well for a pure C1 system.
> Also, in the context of C1, do performance benefits justify additional implementation complexity? As an alternative, migrating `MacroAssembler::check_klass_subtype_slow_path` away from linear search to a table lookup would also do the job and cover all cases of subtype checks in the JVM.
Table lookup needs more registers than a simple linear scan. We'd either have to fix every caller to pass more scratch registers or push and pop some registers in the lookup routine. Given that the time to do a table lookup is in the ns range, pushing and popping a few registers might make it uncompetitive.
I'll have a look.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19426#issuecomment-2146987902
More information about the hotspot-compiler-dev
mailing list