RFR(S/M): 8191789 - migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp
Daniel D. Daugherty
daniel.daugherty at oracle.com
Wed Dec 6 03:39:27 UTC 2017
Thanks for the review!
On 12/5/17 10:38 PM, David Holmes wrote:
> Hi Dan,
> This all looks good to me.
> I agree with removing the now redundant _smr_ name components at a
> later time.
> On 6/12/2017 7:26 AM, Daniel D. Daugherty wrote:
>> I've updated the fix based on Stefan K's code review feedback (and my
>> own self-review)...
>> Delta webrev:
>> Full webrev:
>> Summary of the changes in this round:
>> - moved ThreadsList::remove_thread()
>> - moved ThreadsListSetter::~ThreadsListSetter() and
>> - remove Threads as a friend of class Thread
>> - add ThreadsSMRSupport::update_smr_tlh_stats() to allow more
>> code to be private
>> - refactor Threads-SMR code in Threads::add() to call
>> new function ThreadsSMRSupport::add_thread()
>> - refactor Threads-SMR code in Threads::remove() to call
>> new function ThreadsSMRSupport::remove_thread()
>> - more ThreadsSMRSupport functions can be private
>> - move is_a_protected_JavaThread_with_lock() to
>> I have a Mach5 tier[1-5] in progress for this round...
>> Thanks, in advance, for any comments, questions or suggestions.
>> On 12/4/17 3:22 PM, Daniel D. Daugherty wrote:
>>> In terms of actual "new/changed" code, this is a "S" review. However,
>>> because of code motion, the changed/insert/delete counts are the size
>>> of an "M" or "L" review.
>>> Stefan K, this is one of your Thread-SMR follow-up suggestions so I
>>> to hear from you on this thread. Thanks!
>>> I have a simple (but tedious) cleanup fix for Thread-SMR. The bug is:
>>> JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp ->
>>> This fix is mostly code motion:
>>> - move Thread-SMR related code from thread.cpp -> threadSMR.cpp and
>>> from thread.hpp -> threadSMR.hpp
>>> - move Threads::_smr_* fields -> ThreadsSMRSupport class
>>> - move Thread-SMR functions from Threads -> ThreadsSMRSupport class
>>> - move Thread-SMR helper classes from thread.cpp -> threadsSMR.cpp
>>> - rename a bunch of Threads::foo() calls -> ThreadsSMRSupport::foo()
>>> - collateral changes:
>>> - DO_JAVA_THREADS macro usage by code moved to threadSMR.cpp have
>>> to switch to JavaThreadIterator or some other function.
>>> - Add ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt().
>>> - Add ThreadsSMRSupport::update_smr_java_thread_list_max().
>>> - Cleanup "friends" for Thread class and ThreadsList class.
>>> - Add includes of runtime/threadSMR.hpp in a few files.
>>> Here is the webrev URL:
>>> This fix was (over) tested with a Mach5 tier[1-5] run. There were no
>>> unexpected test failures.
>>> These changes were sanity checked a couple of ways:
>>> - Compare pre-Thread-SMR thread.[ch]pp with thread.[ch]pp after this
>>> - Make sure that remaining Thread-SMR changes in thread.cpp and
>>> thread.hpp make sense to leave behind.
>>> - Similar comparison for thread.inline.hpp.
>>> - Compare code removed from thread.cpp with code added to
>>> compare code removed from thread.hpp with code added to
>>> compare code removed from thread.inline.hpp with code added to
>>> - Make sure the deltas make sense.
>>> Thanks, in advance, for any comments, questions or suggestions.
More information about the hotspot-runtime-dev