On Mon, 5 May 2025 06:27:19 GMT, Radim Vansa <rva...@openjdk.org> wrote:
>> src/hotspot/share/oops/fieldInfo.hpp line 223:
>>
>>> 221: };
>>> 222:
>>> 223: #define JUMP_TABLE_STRIDE 16
>>
>> How was the threshold of 16 determined?
>
> I haven't done any benchmarks looking for the optimal value; this should
> balance the extra memory footprint vs. improved performance. Also I was
> hoping to not affect the bulk of Java code; rather optimize "big" classes
> that show degraded performance due to O(N) lookup.
> How exactly could the optimization function look like if we're to weigh in
> both memory consumption and execution speed?
Since this is also referenced by SA, it should be exported in vmStructs and not
also defined separately in SA. I believe that you can use something like
ObjectMonitor::ANONYMOUS_OWNER as an example of how to do this:
In hotspot:
static const int64_t ANONYMOUS_OWNER = 1;
In vmstructs:
declare_constant(ObjectMonitor::ANONYMOUS_OWNER) \
In SA:
ANONYMOUS_OWNER =
db.lookupLongConstant("ObjectMonitor::ANONYMOUS_OWNER").longValue();
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2085073329
