"product rw" vs "manageable"

[David Holmes]

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 at 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 at 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
>>>
>>
>>