On Mon, 8 May 2023 02:07:25 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> Afaiu, SMR/TLH keeps a terminated thread's TLS accessible, but doesn't stop >> the termination process. >> >> If we initialize result with exited_allocated_bytes, the "too small" >> possibility is still there. We still have a window between that >> initialization and the creation of the threads iterator where threads may >> terminate and thus not be included in the iteration. And new threads may >> become active during the iteration and not be included. As Aleksey observes, >> an advantage is that threads that terminate during the iteration will be >> counted only once and we don't have to check for terminated threads. >> >> If we stick with adding exited_allocated_bytes to result after the >> iteration, Volker is correct that we shouldn't include terminated threads in >> the sum because their allocated bytes values will have been added to >> exited_allocated_bytes. We have the same undercount possibility that >> initializing result with exited_allocated_bytes has, so this (fixed) >> approach can result in "too small" also, but "too large" goes away. >> >> Looks like both approaches are equivalent, so let's go with initializing >> result with exited_allocated_bytes because it avoids a comparison in the >> loop. > >> Afaiu, SMR/TLH keeps a terminated thread's TLS accessible, but doesn't stop >> the termination process. > > Incorrect. A thread cannot complete the termination process if it is > contained by a TLH - see ` ThreadsSMRSupport::smr_delete` and the call to > `wait_until_not_protected`. > > But not sure that helps with the zero-else-double accounting problem. Any > read of the "total accumulated bytes written to date" value is racing with > terminating threads. Resolved, see below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13814#discussion_r1192494925
