"product rw" vs "manageable"

Srinivas Ramakrishna ysr1729 at gmail.com
Wed Jul 26 04:02:40 UTC 2017


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.

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


More information about the hotspot-dev mailing list