Add benchmark to measure performance of VH adapters

[mcimadamore]

This patch adds a straightforward benchmark to measure performances of var handle adapters.

The benchmark is set up to read values from an int array, both with a var handle(obtained from MethodHandles), an associated MethodHandle (derived from the first var handle) and with a segment-based, memory access var handle.

Then the same test is repeated, but with an extra adaptation step inserted in the middle - rather than reading int values directly, the adapter turns ints
into instances of IntBox and the loop code doing the sum converts them back into ints.

Numbers are extremeluy solid on my machine:

TestAdaptVarHandles.mh_box_loop       avgt   30  0.306 ? 0.009  ms/op
TestAdaptVarHandles.mh_loop           avgt   30  0.297 ? 0.009  ms/op
TestAdaptVarHandles.segment_box_loop  avgt   30  0.308 ? 0.009  ms/op
TestAdaptVarHandles.segment_loop      avgt   30  0.307 ? 0.008  ms/op
TestAdaptVarHandles.vh_box_loop       avgt   30  0.296 ? 0.005  ms/op
TestAdaptVarHandles.vh_loop           avgt   30  0.291 ? 0.003  ms/op

I thought it would have been nice to add this to our benchmark suites since we do not have anything that tests VH adaptation directly.

---

Progress

• Change must not contain extraneous whitespace
• Change must be properly reviewed

Reviewers

• Jorn Vernee (jvernee - Committer)
• Paul Sandoz (psandoz - Committer)

Download

$ git fetch https://git.openjdk.java.net/panama-foreign pull/175/head:pull/175
$ git checkout pull/175

[bridgekeeper]

👋 Welcome back mcimadamore! A progress list of the required criteria for merging this PR into foreign-memaccess will be added to the body of your pull request.

[mlbridge]

Webrevs

• 00: Full (c2b9467)

[JornVernee]

With the adapter creating IntBox, this benchmark is also testing whether C2 can eliminate the allocation of the box.

If the goal is to measure an adapted VarHandle against a non-adapted baseline VarHandle, I think it makes sense to have the adapters be the identity function, since then the only difference is whether an adapter is present or not.

WDYT?

[mcimadamore]

I guess my (non stated) goal was to benchmark non trivial adaptation where users could create their own carriers on top of the foreign memory access API. I wanted to make sure that the VH machinery didn't add extra cost when doing so.

[JornVernee]

Looks good

[openjdk]

@mcimadamore This change now passes all automated pre-integration checks, type /integrate in a new comment to proceed. After integration, the commit message will be:

Add benchmark to measure performance of VH adapters

Reviewed-by: jvernee, psandoz

• If you would like to add a summary, use the /summary command.
• To credit additional contributors, use the /contributor command.
• To add additional solved issues, use the /issue command.

Since the source branch of this PR was last updated there has been 1 commit pushed to the foreign-memaccess branch:

• 0bc9c6b: Move MemoryAddress::copy (more review feedback)

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid automatic rebasing, please merge foreign-memaccess into your branch, and then specify the current head hash when integrating, like this: /integrate 0bc9c6bc13acc7c8044219b883bf1e9848a37776.

➡️ To integrate this PR with the above commit message to the foreign-memaccess branch, type /integrate in a new comment.

[mcimadamore]

/integrate

[openjdk]

@mcimadamore The following commits have been pushed to foreign-memaccess since your change was applied:

• 0bc9c6b: Move MemoryAddress::copy (more review feedback)

Your commit was automatically rebased without conflicts.

Pushed as commit e2d2dba.