On Wed, 2 Dec 2020 14:30:57 GMT, Peter Levart <[email protected]> wrote:
>> Thanks for the review, Peter. >> The contract of `updateForm` clearly states that there are no guarantees >> provided about visibility: >> /** >> * Replace the old lambda form of this method handle with a new one. >> * The new one must be functionally equivalent to the old one. >> * Threads may continue running the old form indefinitely, >> * but it is likely that the new one will be preferred for new >> executions. >> * Use with discretion. >> */ >> It is used solely for performance reasons: install a faster LambdaForm >> variant and hope more users catch it. >> >> Regarding `finally`, the intention of `updateInProgress` is to signal that >> there's a thread already preparing an updated form. Once it is done, the >> flag should be set back to `false` to allow more updates in the future. >> Indeed, there's a small window when another thread may succeed in acquiring >> the flag and performing the very same update, but (1) it's benign (it's >> still a performance optimization, so the more threads avoid redundant update >> the better); and (2) there are fast-path checks in place (like `customized >> == mh` in `MH.customize()` or 'oldForm != newForm`) to detect such cases and >> don't waste resources. >> >> Does it resolve your concerns? > > I see. So a MH.form may be updated several times in succession. > I was just concerned that optimization in one part (less resources consumed > updating the form) would increase the probability of JIT-ed code using the > old form indefinitely - therefore causing regression in top performance. If > you think that in spite of MH.form being trusted final field, such > probability stays low, then my concern is unfounded. > Before the patch, each thread that saw opportunity to update form, started > updating form immediately, therefore preventing JIT to kick-in before at > least one of updated forms was installed on MH.form. Now, while one thread is > updating the form, other threads freely execute the old form, so there is > more opportunity for JIT to kick-in during that time and compile a > constant-folded old form. > I wonder if it is possible to construct a concurrent test to provoke that. > WDYT? Would it make a difference if MH.form was not final and each read access to it was done via appropriate Unsafe.getReferenceXXX()? ------------- PR: https://git.openjdk.java.net/jdk/pull/1472
