On Tuesday, 14 January 2014 at 14:22:27 UTC, Timon Gehr wrote:
> On 01/14/2014 10:11 AM, Paulo Pinto wrote:
>> On Monday, 13 January 2014 at 23:42:50 UTC, Timon Gehr wrote:
>>> On 01/13/2014 11:05 PM, Paulo Pinto wrote:
>>>> Am 13.01.2014 22:31, schrieb Timon Gehr:
>>>>> On 01/13/2014 10:11 PM, Walter Bright wrote:
>>>>>>>
>>>>>>> Not to say there aren't other ways of doing things, but with random
>>>>>>> objects
>>>>>>> becoming pinnable puts a big damper on things unless you can identify
>>>>>>> all the
>>>>>>> objects that might be pinned and isolate them.  But I doubt that's
>>>>>>> really
>>>>>>> knowable up front.
>>>>>>
>>>>>> The reason pinning doesn't particularly impede this is because pinning
>>>>>> is rare.
>>>>>
>>>>> In Java or in D? Eg. there are no unions in Java.
>>>>
>>>> C# has unions.
>>>>
>>>> http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.structlayoutattribute%28v=vs.110%29.aspx
>>>>
>>>>
>>>
>>> "The common language runtime controls the physical layout of the data
>>> fields of a class or structure in managed memory. However, ..."
>>
>>
>> Did you also read the remaining part of the page,
>
> Obviously.
>
>> or just looked for something to paste?
>> ...
>
> Look, you hadn't done anything besides pasting for backing up your point or making it precise. I'll be proven wrong if you are able to show us how you do the following in C#:
>
> union U{
>     int x;
>     Object y;
> }
>
>> You can control the layout, that is what matters.  Not at what level you
>> are expressing it.
>> ...
>
> Obviously.
>
>> Ignoring what such runtimes offer, only puts D at disadvantage when
>> comparing feature lists, which many in the industry do.
>>...
>
> Every resource I have encountered indicates that C# does not offer this functionality because it is detrimental to GC, eg:
>
> http://stackoverflow.com/questions/17771902/struct-memory-hack-to-overlap-object-reference-is-it-possible


Excuse me for being stupid.

I just read MSDN without trying it out, so I wasn't aware that object references cannot be made to overllap with other data, even in unsafe structs.

Me and my big mouth. Better test it properly next time.

--
Paulo

On 01/15/14 02:54, Rainer Schuetze wrote:
> On Monday, 13 January 2014 at 22:48:37 UTC, evansl wrote:
>> On 01/11/14 03:30, Rainer Schuetze wrote:
>>>
>>>
>>> On 10.01.2014 22:42, Andrei Alexandrescu wrote:
>> [snip]
>>>> std.emplace will continue to work as a way to build an object at a
>>>> specified address. I suspect that allocating and manipulating
>>>> objects on
>>>> the GC heap in particular may have certain restrictions. One
>>>> possibility
>>>> to avoid such restrictions is to have a function typify(T)(void* p)
>>>> which ascribes type T to heap location p.
>>>
>>> That sounds similar to my gc_emplace function. The problematic part is
>>> how to save that information in the GC.
>>>
>> [snip]
>> Couldn't you store a pointer to the typeinfo within the
>> allocated memory? IOW, the first part of the allocated memory
>> would be the typeinfo* followed by the actual memory used to store the
>> value of the allocated T object.
>>
>> -regards,
>> Larry
>
> std.emplace can be used on a partial memory block (e.g. as part
> of a struct), so you will have to add the emplaced type info in
> addition to the outer struct's type info. There can be multiple
> areas with emplaced dta within the same memory allocation, too.
> So you'll need to store a list of type infos paired with the
> offsets within the meory block. How do you do this efficiently
> without extra cost for the usual scanning?

I'm afraid I'm not familiar with much of what you're talking about.
However, in another thread, containing this post:

http://forum.dlang.org/post/ldhquc$11ec$1@digitalmars.com

Benjamin mentioned RTInfo*.  Which made me think that instead of
pointer to the typeinfo, what about a RTInfo pointer which, according
to comments at:

https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/object_.d#L1101

is the data for precise GC.  Surely if RTInfo contains the data for
precise GC, then that would work.  However, I'm guessing that RTInfo*
is only available for class types.  OTOH, couldn't the compiler figure
out the similar information for struct types?  Then, if a class type
were being scanned, use the existing RTInfo* in the object supertype.
OTOH, if a struct type type is being scanned, then use the compiler
generated RTInfo for the struct type, a pointer to which could be
placed in the heap memory just before the memory for the struct.  I
guess the scanner would then have to be able to figure out if a void*
was pointing to a struct or a class and behave accordingly.

Of course I'm probably missing something, coming from a c++
background; hence, I'd appreciate someone pointing out what I'm
missing.

-regards,
Larry