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.hol...@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 <rednaxel...@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 <ysr1...@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
>>>>
>>>>
>>>
>>>
