On Wed, 24 Jul 2024 16:14:47 GMT, Andrew Haley <[email protected]> wrote:
>>> I suspect that Klass::search_secondary_supers() won't be inlinined in such
>>> case.
>>
>> That's true, but it's true of every other function in that file. Is it not
>> deliberate?
>
> FYI, somewhat related: AArch64 GCC inlines `lookup_secondary_supers_table()`
> 237 times (it's only a few instructions.)
> x86-64 GCC, because it doesn't use a popcount intrinsic, decides that
> `lookup_secondary_supers_table()` is too big to be worth inlining in all but
> 3 cases. So the right thing happens, I think: where we can profit from fast
> lookups without bloating the runtime, we do.
> That's true, but it's true of every other function in that file. Is it not
> deliberate?
IMO the fact that `Klass::search_secondary_supers()` is used in `klass.hpp`
makes a difference here.
After thinking more about it, I did a small experiment [1] and observed a build
failure on AArch64 [2].
I think we don't see any more failures simply because `klass.inline.hpp` is
included pervasively.
What do you think about moving `Klass::is_subtype_of()` to `klass.inline.hpp`?
[1]
diff --git a/test/hotspot/gtest/oops/test_klass.cpp
b/test/hotspot/gtest/oops/test_klass.cpp
new file mode 100644
index 00000000000..326a70f1f54
--- /dev/null
+++ b/test/hotspot/gtest/oops/test_klass.cpp
@@ -0,0 +1,9 @@
+#include "precompiled.hpp"
+#include "oops/klass.hpp"
+#include "unittest.hpp"
+
+TEST_VM(Klass, is_subtype_of) {
+ Klass* k = vmClasses::Object_klass();
+ ASSERT_TRUE(k->is_subtype_of(k));
+}
[2]
Undefined symbols for architecture arm64:
"Klass::search_secondary_supers(Klass*) const", referenced from:
Klass_is_subtype_of_vm_Test::TestBody() in test_klass.o
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1690472489
