Save complex OS-level I/O to know the CPU topology

[franz1981]

This is related smallrye/smallrye-common#370 since smallrye-common exposes CacheInfo as a public API and dropping it can impact existing users - while doing it here, won't impact anyone.

The benefits are quarkusio/quarkus#45436

[franz1981]

@dmlloyd we have no coverage for this unless we run our test suite with -XX:ActiveProcessorCount=1
so please take a look if I did something wrong

[dmlloyd]

This PR will conflict with #215 so we should coordinate somehow.

[franz1981]

since is a small change @dmlloyd here, feel free to cp into your branch without authoring me ❤️

[Sanne]

Could we take it a step further?

• 3de2a0a

[dmlloyd]

The library exists to be used. I'd rather change the logic of the library so that it assumes a reasonable cache line size (perhaps based on something that is faster to ascertain, or just with a sane default) and allows a system property override (with values of, for example, detect, 256, 64, etc.) for edge cases where the default is not suitable.

[geoand]

I vote for having a sane default and having people opt-in to more complex handling as:

• The default is probably fine for almost all cases we are trying to address
• Trying to figure out the actual cache line info is one of the few things whose elimination has an undeniably measurable impact (especially on Mac)

[franz1981]

@dmlloyd do you think we can make this one to slip in first? So we can take our time into verifying that Unsafe-less we don't regress in runtime perf too - not just RSS? 🙏

[dmlloyd]

I think we should fix this only in smallrye-common. Otherwise, as soon as someone else uses those functions, we'll pay the cost anyway, and we'll end up with two different analyses of cache lines.

[geoand]

smallrye/smallrye-common#389 is a simply way to do that