New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8193559: ugly DO_JAVA_THREADS macro should be replaced #4671
Changes from all commits
3f653c5
5ee4991
a133ca4
3be5dc7
a8865b8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
@@ -33,6 +33,57 @@ | ||
#include "memory/iterator.hpp" | ||
#include "runtime/prefetch.inline.hpp" | ||
#include "runtime/thread.inline.hpp" | ||
#include "utilities/debug.hpp" | ||
#include "utilities/macros.hpp" | ||
|
||
ThreadsList::Iterator::Iterator(ThreadsList* list, uint i) : | ||
_thread_ptr(list->threads() + check_index(list, i)) | ||
DEBUG_ONLY(COMMA _list(list)) | ||
{} | ||
|
||
bool ThreadsList::Iterator::operator==(Iterator i) const { | ||
assert_not_singular(); | ||
assert_same_list(i); | ||
return _thread_ptr == i._thread_ptr; | ||
} | ||
|
||
bool ThreadsList::Iterator::operator!=(Iterator i) const { | ||
return !operator==(i); | ||
} | ||
|
||
JavaThread* ThreadsList::Iterator::operator*() const { | ||
assert_not_singular(); | ||
assert_dereferenceable(); | ||
Prefetch::read(const_cast<JavaThread**>(_thread_ptr), PrefetchScanIntervalInBytes); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This prefetch is included because the old code had it. But I'm dubious about it. This is just linear iteration through an array, which seems like the canonical best case for leaving it to the hardware, rather than doing cachelinesize/ptrsize software prefetches per cache line. I'm hoping the original authors can comment. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The original author that added the prefetch is @fisk. He's reviewed an earlier There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree that it should be okay without prefetch. I added it when I was running on a 4096 strand SPARC machine running over 8000 threads, and walking the list would approach 1 ms. While intuitively linear scan should be good enough, I did actually measure slight improvements with explicit prefetching, and the slight improvements did seem worth it at the time as the amount of time spent in there was non-trivial. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm going to leave resolution of the prefetch question to a follow-up bug. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK. |
||
return *_thread_ptr; | ||
} | ||
|
||
JavaThread* ThreadsList::Iterator::operator->() const { | ||
return operator*(); | ||
} | ||
|
||
ThreadsList::Iterator& ThreadsList::Iterator::operator++() { | ||
assert_not_singular(); | ||
assert_dereferenceable(); | ||
++_thread_ptr; | ||
return *this; | ||
} | ||
|
||
ThreadsList::Iterator ThreadsList::Iterator::operator++(int) { | ||
assert_not_singular(); | ||
assert_dereferenceable(); | ||
Iterator result = *this; | ||
++_thread_ptr; | ||
return result; | ||
} | ||
|
||
ThreadsList::Iterator ThreadsList::begin() { | ||
return Iterator(this, 0); | ||
} | ||
|
||
ThreadsList::Iterator ThreadsList::end() { | ||
return Iterator(this, length()); | ||
} | ||
|
||
// Devirtualize known thread closure types. | ||
template <class T> | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't that just be a '<' check?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, less-eq is correct. The index being checked here can be 1-past-the-last-element, for an end-iterator. Including 0 for an empty sequence.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay - thanks for explaining.