One more comment on the JVMTI spec
update (jvmti.xml).
In the Heap Monitoring section new typedefs are defined:
Call Frame
typedef struct {
jint bci;
jmethodID method_id;
} jvmtiCallFrame;
Stack Trace
typedef struct {
JNIEnv* env_id;
jvmtiCallFrame* frames;
jint frame_count;
jint size;
jlong thread_id;
} jvmtiStackTrace;
I think, it'd make sense to use similar typedefs defined in the
Stack Frame section:
jvmtiFrameInfo and jvmtiStackInfo
Thanks,
Serguei
On 6/27/17 23:58, serguei.spit...@oracle.com wrote:
Hi JC,
Sorry for a latency in reply.
I'm going to a 4-week vacation.
But I'll try to help you occasionally when there will be
access to the Internet.
On 6/23/17 09:58, JC Beyler wrote:
Hi Serguei and all,
Thanks Serguei for your review. I believe I have not
answered many questions but raised more but I hope this
helps understand what I am trying to do.
I have inlined my answers to make it easier to answer
everything (and to be honest, ask questions).
. . .
I see a couple of more emails from you.
Will try to help when you have some problems or questions.
Expectable. :)
Right.
I agree, this will allow to make a progress and get more
experience first.
You can look at these two functions in the
jvmtiManageCapabilities.cpp:
144 jvmtiCapabilities
JvmtiManageCapabilities::init_always_solo_capabilities() {
145 jvmtiCapabilities jc;
146
147 memset(&jc, 0, sizeof(jc));
148 jc.can_suspend = 1;
149 return jc;
150 }
151
152
153 jvmtiCapabilities
JvmtiManageCapabilities::init_onload_solo_capabilities() {
154 jvmtiCapabilities jc;
155
156 memset(&jc, 0, sizeof(jc));
157 jc.can_generate_field_modification_events = 1;
158 jc.can_generate_field_access_events = 1;
159 jc.can_generate_breakpoint_events = 1;
160 return jc;
161 }
The can_suspend is always solo but other 3 capabilities are onload
solo.
Probably, onload solo would work well for your purpose.
So that it is possible to follow one of these pattern, for
example, can_generate_breakpoint_events.
You can check all uses of it in the JVMTI spec and the hotspot
sources.
Also, look at the generated file:
build/linux-x86_64-normal-server-release/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp
(You may have different kind of build so, just replace the
suffix "linux-x86_64-normal-server-release" with yours.
You will find a couple of conditions like this:
2873 if
(jvmti_env->get_capabilities()->can_generate_breakpoint_events
== 0) {
2874 return JVMTI_ERROR_MUST_POSSESS_CAPABILITY;
2875 }
In your case such checks will be also auto-generated from your
version of the jvmti.xml.
The newly generated jvmti.html can be found in the same build
folder too.
You may need to look at this JVMTI spec section:
http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#capability
on how to add the needed capability.
Please, ask questions if you have.
I hope, somebody will be able to answer, or I'll do it when get a
chance.
Thanks,
Serguei
I agree, it is better at least to document this behavior.
I need to think more on this.
The whole style is different than that used in the JVMTI.
Normally, each agent does some steps like the following:
- add the capabilities required by the agent (normally in the
ONLOAD phase)
- set the agent event callbacks
- enable/disable event notification mode
- relinquish the capabilities that are not needed anymore
In your approach there is no tight association with any agent
yet.
Also, it seems, the heap monitoring initialization/finalization
are not separated from sampling starting/stopping.
The heap allocation events are processed by the VM itself (in GC
or JVMTI).
It is not clear yet if it could be somehow adjusted to JVMTI
style
and if it is really necessary.
I do not think it is really important to support multi-agents
here.
However, it is important to make a choice sooner rather than
later as it impacts the design.
Thanks,
Serguei
|