Optimizing zero-length arrays in MBeans code

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

All,

I'm looking at https://bz.apache.org/bugzilla/show_bug.cgi?id=58577 to
see how things can be improved. When looking at the method mentioned
in the bug (which is identical to the current git HEAD), the first
thing I noticed was that two zero-length arrays are being created for
each invocation of the mbean operation.

That's (minimally) wasteful, and those objects shouldn't be used for
anything else, so I was thinking I'd just create a pair of static
empty arrays and use those on that line of code.

I searched within the modeler package and I can see some other places
where zero-length arrays are being used, and could share these static
empty arrays.

Before I make this micro-optimization, I was wondering if anyone has
any fears, suspicions, etc. about sharing these objects across
threads. The arrays themselves are immutable in the sense that their
contents cannot be changed (they can't store any values, so there are
no contents to change), but they *can* be used as object monitors for
locking across threads.

There is no telling what a method will do with arguments passed-in to
them, but the MBean operation invocation likely just uses the arrays
of parameters as a transport mechanism for the parameter values. The
array itself should not be used for anything "important" and the
target method should never see this array.

Does anyone know if JMX provides any guarantees about the array
objects passed-into these plumbing methods? Or, on the contrary, do
they specifically warn against using shared-objects?

Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4UmfYACgkQHPApP6U8
pFimWBAArS8NQdASLPl6SmogPbV3a8LvhwiIjsXbiBeePzSp+WeFc/aVf2Q8O1bg
bgCn8wz13qL+vJn9uWS0zxMD0eKPgcsKX+tzGKmi1MKhrcd5AcmM8mjP29zJfehX
cRPOjyAa/Rxvvy9TdSPaBoKRHwU6kKiNPswuReyiDLSJgHY1F0mW3W+l0uzoe3m9
b3MNt8nqbB9md0jWCciYYhn3is4q9JfvwOEVczuk2ghOVN3opT4I/5sorPeibSvg
6ml9CbBrg7O+iqMnOhoB/Iu89uzTcFlDMwmkhJNEvGqs/dZlWRV3WJ07sVFxD6BX
o5+LB6YsccBQLymDTAANeE09NjdpaBL+UFpYR3pSADRMxRnTQK1Xx3c+NvNXSXoq
ZcxQu0SZo/4BxafViw9+PnvJ+3LnKG9HYLneKZdb7odF5EJ8Tp8FniA38UcAlH4H
12o+ql4wzMFgXWRoAM7+SUrcWk/OgFWZCo3tfxjRiDN6BtdbGQgf7oGxGgrIRMYA
9ZG4nGYxuKepxy4PTuc19QWPfUrgrt2MM9bUA4/WtqEQNXvZ+LmFxyU6wOkqvSU8
0jPEJgQ1Y2vefZDh2unqVjLRXUkhZabez5wAHX02BYum2CbvyIN3aqmCPcNuT8oL
db5sYJ1Rzfptp1fcmDnVXeBbui3FlH5sa5yFmB88PMS//xXZa8Q=
=Guco
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org