[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: Re: "product rw" vs "manageable"
From: Srinivas Ramakrishna <ysr1729 () gmail ! com>
Date: 2017-07-26 15:38:24
Message-ID: CABzyjy=x8uyPZMgPyoqwJbUx01O7STR2Cq1=wPMntzS85yohfw () mail ! gmail ! com
[Download RAW message or body]
Thanks for your comments, David! I'll wait for further comments, if any,
from serviceability folk.
-- ramki
On Tue, Jul 25, 2017 at 11:15 PM, David Holmes <david.holmes@oracle.com>
wrote:
> On 26/07/2017 2:02 PM, Srinivas Ramakrishna wrote:
>
>> Ah, Thanks Kris! I'll assume there was no real reason to make it difficult
>> to set the flag through jinfo, then, as I don't see why the logic of
>> setting these flags needs to be so convoluted.
>>
>> If anyone recalls any reasoned history for this difference in behaviour,
>> please let me know. (It's OK to say, "that's a bug in jinfo" or "that's a
>> bug in jmm"; else i'll assume it's the former :-) and the flags should be
>> settable from jinfo, except that the flags themselves do not constitute a
>> stable api.
>>
>
> That's really a question for serviceability folk - cc'd - but I think
> jinfo should only allow setting of the exported external flags ie
> manageable ones. For hotspot internal flags (product_rw) you use a hotspot
> specific mechanism - i.e HotspotMXBean. So no bug here IMHO. But these
> lines are blurrier now than they used to be I think :)
>
> David
>
>
>
> thanks,
>> -- ramki
>>
>> On Tue, Jul 25, 2017 at 5:20 PM, Krystal Mok <rednaxelafx@gmail.com>
>> wrote:
>>
>> Hi Ramki,
>>>
>>> In the current JDK8u HotSpot, jinfo -flag is implemented in the attach
>>> listener as:
>>>
>>> 344 // Implementation of "setflag" command
>>> 345 static jint set_flag(AttachOperation* op, outputStream* out) {
>>> 346
>>> 347 const char* name = NULL;
>>> 348 if ((name = op->arg(0)) == NULL) {
>>> 349 out->print_cr("flag name is missing");
>>> 350 return JNI_ERR;
>>> 351 }
>>> 352
>>> 353 Flag* f = Flag::find_flag((char*)name, strlen(name));
>>> 354 if (f && f->is_external() && f->is_writeable()) {
>>> 355 if (f->is_bool()) {
>>> 356 return set_bool_flag(name, op, out);
>>> 357 } else if (f->is_intx()) {
>>> 358 return set_intx_flag(name, op, out);
>>> 359 } else if (f->is_uintx()) {
>>> 360 return set_uintx_flag(name, op, out);
>>> 361 } else if (f->is_uint64_t()) {
>>> 362 return set_uint64_t_flag(name, op, out);
>>> 363 } else if (f->is_ccstr()) {
>>> 364 return set_ccstr_flag(name, op, out);
>>> 365 } else {
>>> 366 ShouldNotReachHere();
>>> 367 return JNI_ERR;
>>> 368 }
>>> 369 } else {
>>> 370 return AttachListener::pd_set_flag(op, out);
>>> 371 }
>>> 372 }
>>>
>>> So the reason why you're not able to set a product_rw flag through jinfo
>>> is because:
>>>
>>> 282 // All flags except "manageable" are assumed to be internal flags.
>>> 283 // Long term, we need to define a mechanism to specify which flags
>>> 284 // are external/stable and change this function accordingly.
>>> 285 bool Flag::is_external() const {
>>> 286 return is_manageable() || is_external_ext();
>>> 287 }
>>>
>>> But through MXBean "HotSpotDiagnosticMXBean", you can actually set
>>> product_rw flags without any problems. Try setting the flag with JConsole
>>> or VisualVM or any other JMX client and you'll see.
>>>
>>> That's because jmm_SetVMGlobal() only checks whether or not a flag is
>>> writeable, but doesn't check if it's external.
>>>
>>> - Kris
>>>
>>> On Tue, Jul 25, 2017 at 3:35 PM, Srinivas Ramakrishna <ysr1729@gmail.com
>>> >
>>> wrote:
>>>
>>> Today I had occasion to want to switch on what I thought was a
>>>> "manageable"
>>>> flag in a running JVM (TraceClass{Unl,L}oading), and I found that the
>>>> flags
>>>> were declared "product_rw" which is documented as:
>>>>
>>>> // product_rw flags are writeable internal product flags.
>>>> // They are like "manageable" flags but for internal/private use.
>>>> // The list of product_rw flags are internal/private flags which
>>>> // may be changed/removed in a future release. It can be set
>>>> // through the management interface to get/set value
>>>> // when the name of flag is supplied.
>>>> //
>>>> // A flag can be made as "product_rw" only if
>>>> // - the VM implementation supports dynamic setting of the flag.
>>>> // This implies that the VM must *always* query the flag variable
>>>> // and not reuse state related to the flag state at any given time.
>>>>
>>>> I assumed this just meant that the flags were like "manageable" but not
>>>> "supported" (in the sense of constituting a stable interface).
>>>> However, I was surprised to find that I wasn't able to modify these
>>>> flags
>>>> via jinfo, which instead elicited the following error:
>>>>
>>>> $ jinfo -flag +TraceClassUnloading 26136
>>>> -XX:-TraceClassUnloading
>>>>
>>>> $ jinfo -flag +TraceClassUnloading 26136
>>>> Exception in thread "main"
>>>> com.sun.tools.attach.AttachOperationFailedException: flag
>>>> 'TraceClassUnloading' cannot be changed
>>>>
>>>> at
>>>> sun.tools.attach.LinuxVirtualMachine.execute(LinuxVirtualMac
>>>> hine.java:269)
>>>> at
>>>> sun.tools.attach.HotSpotVirtualMachine.executeCommand(HotSpo
>>>> tVirtualMachine.java:261)
>>>> at
>>>> sun.tools.attach.HotSpotVirtualMachine.setFlag(HotSpotVirtua
>>>> lMachine.java:234)
>>>> at sun.tools.jinfo.JInfo.flag(JInfo.java:140)
>>>> at sun.tools.jinfo.JInfo.main(JInfo.java:81)
>>>>
>>>> So, what do "product_rw" flags represent, and can they be changed (using
>>>> jinfo or similar)?
>>>>
>>>> thanks!
>>>> -- ramki
>>>>
>>>>
>>>
>>>
[Attachment #3 (text/html)]
<div dir="ltr">Thanks for your comments, David! I'll wait for further comments, \
if any, from serviceability folk.<div><br></div><div>-- ramki</div></div><div \
class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 25, 2017 at 11:15 PM, \
David Holmes <span dir="ltr"><<a href="mailto:david.holmes@oracle.com" \
target="_blank">david.holmes@oracle.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><span class="">On 26/07/2017 2:02 PM, Srinivas Ramakrishna \
wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> Ah, Thanks Kris! I'll assume there was no real \
reason to make it difficult<br> to set the flag through jinfo, then, as I don't \
see why the logic of<br> setting these flags needs to be so convoluted.<br>
<br>
If anyone recalls any reasoned history for this difference in behaviour,<br>
please let me know. (It's OK to say, "that's a bug in jinfo" or \
"that's a<br> bug in jmm"; else i'll assume it's the former :-) \
and the flags should be<br> settable from jinfo, except that the flags themselves do \
not constitute a<br> stable api.<br>
</blockquote>
<br></span>
That's really a question for serviceability folk - cc'd - but I think jinfo \
should only allow setting of the exported external flags ie manageable ones. For \
hotspot internal flags (product_rw) you use a hotspot specific mechanism - i.e \
HotspotMXBean. So no bug here IMHO. But these lines are blurrier now than they used \
to be I think :)<span class="HOEnZb"><font color="#888888"><br> <br>
David</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> thanks,<br>
-- ramki<br>
<br>
On Tue, Jul 25, 2017 at 5:20 PM, Krystal Mok <<a \
href="mailto:rednaxelafx@gmail.com" target="_blank">rednaxelafx@gmail.com</a>> \
wrote:<br> <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Hi Ramki,<br>
<br>
In the current JDK8u HotSpot, jinfo -flag is implemented in the attach<br>
listener as:<br>
<br>
344 // Implementation of "setflag" command<br>
345 static jint set_flag(AttachOperation* op, outputStream* out) {<br>
346<br>
347 const char* name = NULL;<br>
348 if ((name = op->arg(0)) == NULL) {<br>
349 out->print_cr("flag name is missing");<br>
350 return JNI_ERR;<br>
351 }<br>
352<br>
353 Flag* f = Flag::find_flag((char*)name, strlen(name));<br>
354 if (f && f->is_external() && f->is_writeable()) {<br>
355 if (f->is_bool()) {<br>
356 return set_bool_flag(name, op, out);<br>
357 } else if (f->is_intx()) {<br>
358 return set_intx_flag(name, op, out);<br>
359 } else if (f->is_uintx()) {<br>
360 return set_uintx_flag(name, op, out);<br>
361 } else if (f->is_uint64_t()) {<br>
362 return set_uint64_t_flag(name, op, out);<br>
363 } else if (f->is_ccstr()) {<br>
364 return set_ccstr_flag(name, op, out);<br>
365 } else {<br>
366 ShouldNotReachHere();<br>
367 return JNI_ERR;<br>
368 }<br>
369 } else {<br>
370 return AttachListener::pd_set_flag(op<wbr>, out);<br>
371 }<br>
372 }<br>
<br>
So the reason why you're not able to set a product_rw flag through jinfo<br>
is because:<br>
<br>
282 // All flags except "manageable" are assumed to be internal flags.<br>
283 // Long term, we need to define a mechanism to specify which flags<br>
284 // are external/stable and change this function accordingly.<br>
285 bool Flag::is_external() const {<br>
286 return is_manageable() || is_external_ext();<br>
287 }<br>
<br>
But through MXBean "HotSpotDiagnosticMXBean", you can actually set<br>
product_rw flags without any problems. Try setting the flag with JConsole<br>
or VisualVM or any other JMX client and you'll see.<br>
<br>
That's because jmm_SetVMGlobal() only checks whether or not a flag is<br>
writeable, but doesn't check if it's external.<br>
<br>
- Kris<br>
<br>
On Tue, Jul 25, 2017 at 3:35 PM, Srinivas Ramakrishna <<a \
href="mailto:ysr1729@gmail.com" target="_blank">ysr1729@gmail.com</a>><br> \
wrote:<br> <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Today I had occasion to want to switch on what I thought was \
a<br> "manageable"<br>
flag in a running JVM (TraceClass{Unl,L}oading), and I found that the<br>
flags<br>
were declared "product_rw" which is documented as:<br>
<br>
// product_rw flags are writeable internal product flags.<br>
// They are like "manageable" flags but for internal/private use.<br>
// The list of product_rw flags are internal/private flags which<br>
// may be changed/removed in a future release. It can be set<br>
// through the management interface to get/set value<br>
// when the name of flag is supplied.<br>
//<br>
// A flag can be made as "product_rw" only if<br>
// - the VM implementation supports dynamic setting of the flag.<br>
// This implies that the VM must *always* query the flag variable<br>
// and not reuse state related to the flag state at any given time.<br>
<br>
I assumed this just meant that the flags were like "manageable" but not<br>
"supported" (in the sense of constituting a stable interface).<br>
However, I was surprised to find that I wasn't able to modify these flags<br>
via jinfo, which instead elicited the following error:<br>
<br>
$ jinfo -flag +TraceClassUnloading 26136<br>
-XX:-TraceClassUnloading<br>
<br>
$ jinfo -flag +TraceClassUnloading 26136<br>
Exception in thread "main"<br>
com.sun.tools.attach.AttachOpe<wbr>rationFailedException: flag<br>
'TraceClassUnloading' cannot be changed<br>
<br>
at<br>
sun.tools.attach.LinuxVirtualM<wbr>achine.execute(LinuxVirtualMac<br>
hine.java:269)<br>
at<br>
sun.tools.attach.HotSpotVirtua<wbr>lMachine.executeCommand(HotSpo<br>
tVirtualMachine.java:261)<br>
at<br>
sun.tools.attach.HotSpotVirtua<wbr>lMachine.setFlag(HotSpotVirtua<br>
lMachine.java:234)<br>
at sun.tools.jinfo.JInfo.flag(JIn<wbr>fo.java:140)<br>
at sun.tools.jinfo.JInfo.main(JIn<wbr>fo.java:81)<br>
<br>
So, what do "product_rw" flags represent, and can they be changed \
(using<br> jinfo or similar)?<br>
<br>
thanks!<br>
-- ramki<br>
<br>
</blockquote>
<br>
<br>
</blockquote></blockquote>
</div></div></blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic