RFR: 8183545: Event tracing, transition hooks
Robbin Ehn
robbin.ehn at oracle.com
Wed Jul 5 19:23:02 UTC 2017
Hi Dan,
On 07/05/2017 06:36 PM, Daniel D. Daugherty wrote:
> On 7/5/17 6:28 AM, Robbin Ehn wrote:
>> Hi all,
>>
>> Please review.
>>
>> This patch adds a new bit in suspend flag for the tracing backend.
>> Thus tracing backend can suspend threads on certain transitions.
>>
>> (David H and Dan D have looked at this, that's why they are on CC)
>>
>> I have also put in a oneliner in:
>> src/share/vm/classfile/javaClasses.cpp
>>
>> Which adds Threads_lock->owned_by_self() to the assert.
>> Threads_lock->owned_by_self() give the same guarantees as is_Watcher_thread(), e.g. there is no safepoint.
>>
>> If you really insist I can put the oneliner in a separate issue, but the tracing backend changes depends on both.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8183545
>> Webrev: http://cr.openjdk.java.net/~rehn/8183545/webrev/index.html
>
> src/share/vm/classfile/javaClasses.cpp
> Your comment about this change:
>
> > Threads_lock->owned_by_self() give the same guarantees as
> > is_Watcher_thread(), e.g. there is no safepoint.
>
> confuses me. While it's true if the calling thread owns the
> Threads_lock, we can't be in the middle of a safepoint, I
> don't think that's the reason for the assert. Of course, if
> the calling thread is the VMThread we could be in a safepoint,
> but that was already allowed. I hate it when the reason for a
> non-obvious assert is not commented...
>
> So the original code asserted:
>
> - WatcherThread allowed to call
> - VMThread allowed to call
> - JavaThread in state _thread_in_vm allowed to call
>
> You are adding:
>
> - Threads_lock owner allowed to call
>
> I suspect that the original reason for the assert() was to
> make sure that the caller was doing something VM related
> and your addition of the Threads_lock owner check fits that
> criteria...
>
> A Mercurial history check shows:
>
> 0: java_lang_Thread::ThreadStatus java_lang_Thread::get_thread_status(oop java_thread) {
> 4802: assert(Thread::current()->is_Watcher_thread() || Thread::current()->is_VM_thread() ||
> 0: JavaThread::current()->thread_state() == _thread_in_vm,
> 0: "Java Thread is not running in vm");
>
> shows two of the lines come from the original import into
> Mercurial (back in JDK7). The line you're changing was
> changed since then:
>
> $ hg log -r 4802 src/share/vm/classfile/javaClasses.cpp
> changeset: 4802:f2110083203d
> user: sla
> date: Mon Jun 10 11:30:51 2013 +0200
> summary: 8005849: JEP 167: Event-Based JVM Tracing
>
> The line before changeset 4802 was:
>
> 0: assert(Thread::current()->is_VM_thread() ||
>
> $ hg diff -r 4801 -r 4802 src/share/vm/classfile/javaClasses.cpp
> diff -r d0add7016434 -r f2110083203d src/share/vm/classfile/javaClasses.cpp
> --- a/src/share/vm/classfile/javaClasses.cpp Fri Jun 07 09:33:01 2013 -0700
> +++ b/src/share/vm/classfile/javaClasses.cpp Mon Jun 10 11:30:51 2013 +0200
> @@ -961,7 +961,7 @@
>
> // Read thread status value from threadStatus field in java.lang.Thread java class.
> java_lang_Thread::ThreadStatus java_lang_Thread::get_thread_status(oop java_thread) {
> - assert(Thread::current()->is_VM_thread() ||
> + assert(Thread::current()->is_Watcher_thread() || Thread::current()->is_VM_thread() ||
> JavaThread::current()->thread_state() == _thread_in_vm,
> "Java Thread is not running in vm");
> // The threadStatus is only present starting in 1.5
>
> So JEP 167 added "Thread::current()->is_Watcher_thread()" and now
> we want to add "Threads_lock->owned_by_self()"... can the previous
> condition be removed or do we now need both?
>
> I'm wondering if adding a comment like this would make future
> readings of this code more clear:
>
> // Make sure the caller is operating on behalf of the VM or is
> // running VM code (state == _thread_in_vm).
Good digging, I think we can remove is_Watcher_thread from assert, get_thread_status is never called from Watcher thread.
(I'll run some tests also)
>
> src/share/vm/runtime/thread.cpp
> No comments.
>
> src/share/vm/runtime/thread.hpp
> L457: bool is_trace_suspend() { return (_suspend_flags & _trace_flag) != 0; }
> nit: indent for '{' is off by two space relative to the other
> functions above and below it.
>
> L1269: // We call is_external_suspend() last since external suspend should
> L1270: // be less common.
> <snip>
> L1279: return (_special_runtime_exit_condition != _no_async_condition) ||
> L1280: is_external_suspend() || is_deopt_suspend() || is_trace_suspend();
> Not your fault, but the quoted comment is wrong. I'm guessing
> it has been wrong since is_deopt_suspend() was added to the
> expression. Don't know if is_deopt_suspend() was added last
> for a reason or not. I would think that is_deopt_suspend()
> would be more frequent than external suspension.
>
> Looks like the s_deopt_suspend() conditional was added by this
> Teamware delta:
>
> $ sp -r1.442.1.1 src/share/vm/runtime/thread.hpp
> src/share/vm/runtime/SCCS/s.thread.hpp:
>
> D 1.442.1.1 06/12/07 10:06:52 sgoldman 1059 1057 00017/00003/01722
> MRs:
> COMMENTS:
> 6463133 - patchless deopt. Support specialized deopt suspend for
> register window based machines.
Fixed!
>
> src/share/vm/runtime/thread.inline.hpp
> No comments.
>
> src/share/vm/trace/traceMacros.hpp
> No comments.
>
>
> Thumbs up on the change! If you fix the the nits above, I don't need
> to see a new webrev. I'm interested in what you decide to do about
> the src/share/vm/classfile/javaClasses.cpp assert, but that doesn't
> need to hold up this review.
Thanks!
/Robbin
>
> Dan
>
>
>>
>> Test: openjdk build on Linux x64
>>
>> Thanks!
>>
>> /Robbin
>
More information about the hotspot-runtime-dev
mailing list