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
