Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8268155 | 18 | Leonid Mesnik | P4 | Closed | Not an Issue | b26 |
Case 1:
void ThreadTimesClosure::do_unlocked() {
EXCEPTION_MARK;
for (int i = 0; i < _count; i++) {
Handle s = java_lang_String::create_from_str(_names_chars[i], CHECK);
_names_strings->obj_at_put(i, s());
}
}
create_from_str can throw OOME as per the use of CHECK macro, but the EXCEPTION_MARK would cause us to crash if this happened. The EXCEPTION_MARK is not wanted here.
case 2:
void ThreadTimesClosure::do_thread(Thread* thread) {
...
EXCEPTION_MARK;
ResourceMark rm(THREAD); // thread->name() uses ResourceArea
assert(thread->name() != NULL, "All threads should have a name");
_names_chars[_count] = os::strdup(thread->name());
_times->long_at_put(_count, os::is_thread_cpu_time_supported() ?
os::thread_cpu_time(thread) : -1);
_count++;
}
This EXCEPTION_MARK is superfluous as no code raises exceptions.
If the code wants to assert it is not called with an exception pending then it should assert that directly rather than using the EXCEPTION_MARK.
void ThreadTimesClosure::do_unlocked() {
EXCEPTION_MARK;
for (int i = 0; i < _count; i++) {
Handle s = java_lang_String::create_from_str(_names_chars[i], CHECK);
_names_strings->obj_at_put(i, s());
}
}
create_from_str can throw OOME as per the use of CHECK macro, but the EXCEPTION_MARK would cause us to crash if this happened. The EXCEPTION_MARK is not wanted here.
case 2:
void ThreadTimesClosure::do_thread(Thread* thread) {
...
EXCEPTION_MARK;
ResourceMark rm(THREAD); // thread->name() uses ResourceArea
assert(thread->name() != NULL, "All threads should have a name");
_names_chars[_count] = os::strdup(thread->name());
_times->long_at_put(_count, os::is_thread_cpu_time_supported() ?
os::thread_cpu_time(thread) : -1);
_count++;
}
This EXCEPTION_MARK is superfluous as no code raises exceptions.
If the code wants to assert it is not called with an exception pending then it should assert that directly rather than using the EXCEPTION_MARK.
- backported by
-
JDK-8268155 ThreadTimesClosure doesn't handle exceptions properly
- Closed
- relates to
-
JDK-7196045 Possible JVM deadlock in ThreadTimesClosure when using HotspotInternal non-public API.
- Closed