Oleg Kalnichevski wrote:
given the fact that register optimizations are very, very
short-lived.
Isn't it best not to rely on the duration of register caching, unless it
truly isn't important for threads to see up-to-date field values? We
see short duration optimizations today... but a year from now? Two
years from now? One of the servers I work with has multiple multi-core
CPUs and it's a little scary sometimes!
Internally BasicHttpParams is backed by a HashMap instance,
BasicHttpProcessor is backed by two ArrayList instance. There is no
problem making references to those instances final. However, this will
not guarantee in any way that the internal variables of those instances
are also final. Basically we gain nothing.
This is a good observation. You would need to introduce a JMM memory
flush point (e.g. synchronized block) to push out the values of any
non-final/non-volatile fields-of-fields-(etc).
However, even in the face of this issue, if a field can reasonably be
made final/volatile, and that field is shared across threads, even if it
does not eliminate all potential caching issues, I think it should still
be done, just for good measure, and the potential remaining issues
commented in the code.
Also, if there are truly known (even if unobserved) issues with fields
not being cache-safe, and if those issues would result in incorrect
behavior of the code (not just non-performant behavior) it may be most
ideal to introduce a JMM memory flush point such as a synchronized
collection or manually introducing a synchronized block.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
