JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods (original) (raw)

Vitaly Davidovich vitalyd at gmail.com
Tue Jan 31 00:29:55 UTC 2012

I agree that performance of clone vs copy ctor should be irrelevant in the grand scheme of things -- I think this question is purely academic at this point. I think most call sites that call clone() will have just one (maybe two) receiver types, so the guard should predict every time in most cases, and I'd imagine is a cheap check (a type check, which I believe is just a few instructions). As for memcpy, I think some compilers generate better code for it than others by substituting their own version instead of using the library call, including using different instructions depending on amount of data to copy and the machine architecture. Anyway, that's a whole other topic. I think the general point is that calling clone() makes a clearer indication of intent to the JVM, so in theory it should have more room for optimization.

Cheers

On Mon, Jan 30, 2012 at 6:47 PM, Rémi Forax <forax at univ-mlv.fr> wrote:

On 01/30/2012 10:17 PM, Vitaly Davidovich wrote:

I would also expect clone to run a bit faster than copy constructor, if for nothing else than clone not executing any constructor; this perf diff would probably be more noticeable in interpreter as compiler may inline constructor. In addition, I'd also think that clone can basically be equivalent to memcpy which should be faster.

It depends if the class if final or not. If the class is not final the VM will have to add a guard before calling Object.clone(). Object.clone() is intrinsified (lookup for 'intrinsics' in the source code) so it will do a memcopy. A far as I remember, memcopy is slower that copying fields one by one if there is a few fields (otherwise it's faster). Then you need a checkcast at the end and as far as I remember, the VM doesn't remove it. So as Tom said, if the class is final, using a copy constructor is usually faster. Anyway, this is too Hotspot specific and may change in the future, moreover I've never seen a call clone() or to a copy constructor being the performance bottleneck. Stupid algorithms and bad choices of the data structures are far more frequent. Rémi

Sent from my phone On Jan 30, 2012 4:08 PM, "Ulf Zibis"<Ulf.Zibis at gmx.de> wrote: Am 30.01.2012 14:28, schrieb Tom Hawtin:

On 30/01/2012 13:16, Ulf Zibis wrote:

Isn't cloning faster than normal instantiation? I can imagine, that behind the scenes cloning mainly only needs to duplicate the binary footprint of an object.

I don't see a good reason why it should be (equally, I've not tried benchmarking). For the immediate fields of an object, (partial) bitwise copying "by hand" should be of comparable performance to a bitwise clone. For copying the referenced objects, there is no benefit for the clone. Is there anybody, who knows this exactly, e.g. in reference to Hotspot runtime? -Ulf

-- Vitaly 617-548-7007 (mobile)

More information about the core-libs-dev mailing list