"product rw" vs "manageable"

[Krystal Mok]

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(LinuxVirtualMachine.java:269)
> at
> sun.tools.attach.HotSpotVirtualMachine.executeCommand(
> HotSpotVirtualMachine.java:261)
> at
> sun.tools.attach.HotSpotVirtualMachine.setFlag(HotSpotVirtualMachine.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
>