Re: New ABI NSConstantString

[Fred Kiefer]

Am 01.04.2018 um 11:52 schrieb David Chisnall <address@hidden>:
> 
> Hello the list,
> 
> I have nearly finished the ELF version of the new Objective-C ABI.  It is 
> able to pass the same tests that the previous one did in -base, with a 
> smaller binary and better reflection metadata.  The last piece left is 
> whether to improve NSConstantString.
> 
> The new ABI includes some breaking changes, so will require a complete 
> recompile.  This gives us an opportunity to improve constant strings.  I 
> think we have three options:
> 
> 1) Use the existing NSConstantString structure.
> 2) Simply adopt CFConstantString.
> 3) Do something new.
> 
> I don’t think 1 is a very good idea.  -base includes some horribly hacks to 
> go and replace NSConstantString instances with NSString instances on 
> initialisation because NSConstantString -hash requires that it be computed 
> dynamically.
> 
> Option 2 would simplify some Apple interoperability.  It allows UTF-8 and 
> UTF-16 strings (is this useful?  Anyone in CJK locales want it?) but doesn’t 
> really help with the hash issue.  
> 
> Option 3 would be to implement a structure something like:
> 
> {
>       id isa;
>       const char *str; // UTF8 or UTF16 string
>       NSUInteger  hash;
>       NSUInteger  flags;
> }
> 
> The flags would store, at a minimum:
> 
> - Whether this is UTF-8 or UTF-16.
> - What hash algorithm the compiler used.
> 
> If -base later decides to use a different hash algorithm, the implementation 
> of -hash can then check the flags and if the compiler-provided hash is not 
> the version being used, it can lazily set the hash ivar to something 
> different.
> 
> Another alternative is to set isa to different things for UTF8 and UTF16, so 
> we can just provide NSUTF8ConstantString and NSUTF16ConstantString as 
> subclasses of NSConstantString.
> 
> Does anyone have any strong opinions in either direction?

Wouldn’t the most useful structure be the one we already use for GSString?

@interface GSString : NSString
{
@public
  GSCharPtr _contents;
  unsigned int  _count;
  struct {
    unsigned int        wide: 1;        // 16-bit characters in string?
    unsigned int        owned: 1;       // Set if the instance owns the
                                        // _contents buffer
    unsigned int        unused: 2;
    unsigned int        hash: 28;
  } _flags;
}
@end

Of course constant strings won’t require  the hidden reference count that come 
with all ObjC objects. But apart from that it seems to be a more useful 
structure. Storing the length with the string should speed up some common 
operations and 28 bit of hash should still be enough. There are even two unused 
bits in the flags that could encode the specific hash function.