RFR (xs) 8145940: TempNewSymbol should have correct copy and assignment functions

[John Rose]

On Jan 14, 2016, at 11:26 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
>>> If the answer is not "all of them" or "none
>>> of them", we have a manually-enforced distinction which may
>>> turn out to be fragile.
>> 
>> It's all but two.   Yes, it can be fragile.  So the reason for having TempNewSymbol in the first place was to track symbols coming into the JVM via char*, vs. via the constant pool.  At the time it was 90% the constant pool so we didn't want refcounting for every symbol operation, ala smart pointers.  It was a bigger not nice change at the time, and tons of refcounting.  We also really want to manipulate symbols as Symbol* rather than some other name but we've debated this lots of times.

This is totally reasonable, and can be incrementally fixed without polluting the bulk of the code with new refcounting.

I am not worried about Symbol* uses which are piggy-backing on an already-loaded klass.  (I.e., I'm happy to use Symbol* and Klass* pointers most places, as long as there is an associated *Handle somewhere keeping it all pinned down.)

So, simply have the two special API points (and any future API points that also have to be special, but no others) return a TempNewSymbol instead of a Symbol*.

Nearly all of our Symbol-using code stays that same; that's what I was trying to say with the code example:

>> Here's a thought, FWIW, about an incremental way forward on
>> the pre-increment problem.  It might be useful to split the "magic"
>> functions:
>> 
>>   TempNewSymbol lookup(int index, const char* name, int len, unsigned int hash);
>>   TempNewSymbol new_symbol(const char* name, TRAPS) { … }
>>   Symbol* lookup_increment_refcount(int index, const char* name, int len, unsigned int hash);
>>   Symbol* new_symbol_increment_refcount(const char* name, TRAPS) { … }


— John