Hi Arnold,

> Am 15.07.2016 um 02:17 schrieb Arnold <[email protected]>:
> 
>> On Jul 14, 2016, at 4:04 PM, Johannes Neubauer <[email protected]> wrote:
>> 
>> Hi Arnold,
>> 
>> Thank you and [email protected] very much for your answers. That helps 
>> already a lot. Are you Arnold from the WWDC Video?
> 
> Yes.

Cool. Thank you for the great answers. Last words to this topic inline:

>> Are there corresponding plans? Storing „big“ values (using some statistics 
>> to evaluate where the break-even is) as reference types always, storing them 
>> in a big table per type (each value occurs only once) should be possible, 
>> right? Is this something I should post on the swift-evolution mailing list?
> 
> No hashed out plans only discussions on hallways. The swift team  focuses on 
> finishing up swift 3.
> 
> But yes, similar ideas are being discussed.

AFAIK the JVM does such things for Strings (they call it a pool not a table) 
and they use a pool of values as reference types for inboxing/outboxing of 
primitive types to their Wrapper class counterparts (in order to speed this 
process up). So if you put an `int` into a method that expects an `Integer` 
they lookup the corresponding instance of the Wrapper type and return it.

> This a simplification that might overlook specific cases where this is not 
> necessarily true. (The swift compiler can flatten structs to its individual 
> member properties -- scalarize the struct -- and that can lead to better 
> optimization …)

OK. Good to know.

>> Are there already proposals available or is it still in early discussions? 
>> Can you give me a hint where to find more about it?
> 
> No proposals at the moment.

Is there some documentation of the current implementation of Existential 
Container, Protocol Witness Table, and co.? Where do I find it?

> 
> This is an abstract description that does not contradict mine.
> Conceptually the value witness table is a dictionary (value witness's 
> function kind to implementation). It is implemented as a block of memory (a 
> table) that contains pointers to functions. At offset 2 (made up I would have 
> to lookup what the offset is) say you will find the function that knows how 
> to allocate memory for that type.
> For an Int this function will just return a pointer into the inline value 
> buffer.
> 
> For a struct of 4 integers this function will malloc memory on the heap store 
> the pointer into the online value buffer and will return that pointer.

OK, so this table contains 4 entries alloc/dealloc, copy, and destroy and is 
not a table of all values. I got it.

> Buffers for big values are created when we create a protocol value. This code 
> is not clever. It allocates memory on the heap and copies the value's storage 
> to that heap memory.

OK. Thanks.

All the best
Johannes

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev

Reply via email to