JDK 8 code review request for 7140820 Add covariant overrides to Collections clone methods

[Ulf Zibis]

_In theory (am I wrong?):_
- Copy constructor:
1.) allocate memory
2.) individually initialize fields with 0/null
3.) individually initialize fields from initializers
4.) individually initialize fields from super/this constructors (can be many)
5.) individually copy values from original
6.) _optionally_ do some additional work
- Cloning:
1.) allocate memory
2.) copy all values(=memcopy/intrinsic) from original
3.) _optionally_ do some additional work via overriding clone()

_In practice:_
- Thanks for all your detailed answers!

>  I think most call sites that call clone() will have just one (maybe two) receiver types

I was thinking about use cases in factories.
Especially cloning an already prepared master-object seems faster to me, than instantiating and 
post-processing a virgin object.

In a former case, I had to use a given API, Charset#newDecoder(), to retrieve new decoder objects, 
which share a big mapping table object (one for each distinct charset), which was expensive to load. 
So the Charset class should hold a virgin decoder object by SoftReference to temporarily prevent the 
mapping table from GCing, even if no decoder object was in use(=referenced from user code). As the 
decoder object could be of different class type, a concrete (copy)constructor was not accessible.

So I had to decide between _expensive_ (copy)constructor _invocation via reflection_ or, as I think, 
_cheap cloning_.

-Ulf


Am 31.01.2012 01:29, schrieb Vitaly Davidovich:
> 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
>>>>
>>>>
>>>>
>