Re: RFR: 8257074 Update the ByteBuffers micro benchmark [v4]
On Thu, 10 Dec 2020 14:01:56 GMT, Jorn Vernee wrote: >> While the updated set of scenarios covered by this benchmark is >> reasonably (and vastly improves coverage), I find myself reluctant to >> add the last remaining buffer property - read-only views. It's time to >> template the generation of this code! > > If the cases get to be too many, you might also want to consider splitting > the benchmark class into several classes that cover different cases (we did > this for the memory access benchmarks as well). That would also make it > easier to run a subset of cases in isolation. All comments to date have been addressed. Unless there are any further comments, I would like to integrate this change. - PR: https://git.openjdk.java.net/jdk/pull/1430
Re: RFR: 8257074 Update the ByteBuffers micro benchmark [v4]
On Thu, 10 Dec 2020 09:46:07 GMT, Chris Hegarty wrote: >> Marked as reviewed by bpb (Reviewer). > > While the updated set of scenarios covered by this benchmark is > reasonably (and vastly improves coverage), I find myself reluctant to > add the last remaining buffer property - read-only views. It's time to > template the generation of this code! If the cases get to be too many, you might also want to consider splitting the benchmark class into several classes that cover different cases (we did this for the memory access benchmarks as well). That would also make it easier to run a subset of cases in isolation. - PR: https://git.openjdk.java.net/jdk/pull/1430
Re: RFR: 8257074 Update the ByteBuffers micro benchmark [v4]
On Mon, 30 Nov 2020 20:54:09 GMT, Brian Burkhalter wrote: >> Chris Hegarty has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Add explicitly allocated heap carrier buffer tests >> - Replace Single with Loop > > Marked as reviewed by bpb (Reviewer). While the updated set of scenarios covered by this benchmark is reasonably (and vastly improves coverage), I find myself reluctant to add the last remaining buffer property - read-only views. It's time to template the generation of this code! - PR: https://git.openjdk.java.net/jdk/pull/1430
Re: RFR: 8257074 Update the ByteBuffers micro benchmark [v4]
On Mon, 30 Nov 2020 13:39:12 GMT, Chris Hegarty wrote: >> The ByteBuffers micro benchmark seems to be a little dated. >> >> It should be a useful resource to leverage when analysing the performance >> impact of any potential implementation changes in the byte buffer classes. >> More specifically, the impact of such changes on the performance of sharp >> memory access operations. >> >> This issue proposes to update the benchmark in the following ways to meet >> the aforementioned use-case: >> >> 1. Remove allocation from the individual benchmarks - it just creates noise. >> 2. Consolidate per-thread shared heap and direct buffers. >> 3. All scenarios now use absolute memory access operations - so no state of >> the shared buffers is considered. >> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. >> 5. There seems to have been an existing bug in the test where the size >> parameter was not always considered - this is now fixed. > > Chris Hegarty has updated the pull request incrementally with two additional > commits since the last revision: > > - Add explicitly allocated heap carrier buffer tests > - Replace Single with Loop Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1430
Re: RFR: 8257074 Update the ByteBuffers micro benchmark [v4]
> The ByteBuffers micro benchmark seems to be a little dated. > > It should be a useful resource to leverage when analysing the performance > impact of any potential implementation changes in the byte buffer classes. > More specifically, the impact of such changes on the performance of sharp > memory access operations. > > This issue proposes to update the benchmark in the following ways to meet the > aforementioned use-case: > > 1. Remove allocation from the individual benchmarks - it just creates noise. > 2. Consolidate per-thread shared heap and direct buffers. > 3. All scenarios now use absolute memory access operations - so no state of > the shared buffers is considered. > 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. > 5. There seems to have been an existing bug in the test where the size > parameter was not always considered - this is now fixed. Chris Hegarty has updated the pull request incrementally with two additional commits since the last revision: - Add explicitly allocated heap carrier buffer tests - Replace Single with Loop - Changes: - all: https://git.openjdk.java.net/jdk/pull/1430/files - new: https://git.openjdk.java.net/jdk/pull/1430/files/814e1819..5ee5d8bf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=1430=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=1430=02-03 Stats: 407 lines in 1 file changed: 151 ins; 0 del; 256 mod Patch: https://git.openjdk.java.net/jdk/pull/1430.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1430/head:pull/1430 PR: https://git.openjdk.java.net/jdk/pull/1430
