Back VirtualField with a volatile field

[trask]

Tracking issue for discussion item raised in #4262 (comment)

Backing with a volatile field is definitely the safest, but it may also be nice to have the option to back it with a non-volatile field in specific places where we know that's safe.

[mateuszrzeszutek]

but it may also be nice to have the option to back it with a non-volatile field in specific places where we know that's safe.

Are performance gains that come from the field being non-volatile really so significant? Allowing to choose the synchronization model (volatile vs not volatile) when retrieving the field would probably really complicate the already complex VirtualField API and implementation (especially implementation).

[anuraaga]

As with many things, they "can" be very significant. That being said, do we have obvious patterns where non-volatile is OK? I think propagating context is the most common use of virtual field, and this naturally needs to be volatile as it involves multiple threads. Went through a few pages of search results, and I suspect 90+% of usages of VirtualField have the word Context or Async in the value type, I saw a Span (which should probably be Context :O). Exceptions include

• DbInfo - I guess JDBC connection can be read from a different thread when there is a connection pool used form a threadpool like in HikariCP
• Boolean - to verify whether a gRPC resource has already been instrumented or not. There's no performance impact since these are only supposed to be called once / few times per app, not on hot path, due to being innately slow operations.

Didn't dig through all usages, but volatile-only seems to be reasonable to me.

[trask]

Are performance gains that come from the field being non-volatile really so significant?

it may be early for us to be tackling volatile fields, but I did find it helpful when pushing performance in glowroot

depending on specifics, sometimes the needed visibility memory barriers are provided by writing/reading from an execution queue or object pool (unless i'm wrong, which is entirely possible, this stuff is hard)

volatile-only seems to be reasonable to me

👍