On 4/16/2012 4:32 AM, deadalnix wrote:
> Le 16/04/2012 11:25, Walter Bright a écrit :
>> On 4/16/2012 2:05 AM, deadalnix wrote:
>>> Having this template into object.d seems problematic to me. It is now
>>> quite hard
>>> to provide any custom GC implementation without messing with Druntime.
>>>
>>> Providing a user created GC should be as easy as possible.
>>
>> It's never going to be easy for anyone to just write their own GC,
>> especially one that works better than one a lot of people have spent a
>> lot of time on.
>>
>
> I don't think this is easy. But Different GC have different impact on the
> program. For instance, oracle's JVM provide you 4 different GC, that you can
> choose with different configuration parameters.

Those are not user created GCs.


> That is exactly what I meant. Metadata about the block shouldn't be stored
> anywhere near the block, because it will behave horribly wrong when swap come
> into play. Metadata must be read and written when GC does its job, but the block
> itself doesn't require it.

I think the point is that it is not up to the compiler how this is done, but to the GC implementer.

On 16-04-2012 13:34, deadalnix wrote:
> Le 16/04/2012 13:24, Jacob Carlborg a écrit :
>> On 2012-04-16 11:00, Walter Bright wrote:
>>> On 4/16/2012 1:20 AM, Jacob Carlborg wrote:
>>>> I thought it was a first step for runtime reflection.
>>>
>>> The thing about runtime reflection is you only need it for a few
>>> classes, while the compiler is doomed to generate the info for all of
>>> them. Andrei suggested a better design, which was to use compile time
>>> reflection to generate runtime information, as a library routine, on an
>>> as-needed basis.
>>
>> If we can't relay on runtime reflection being there it's basically
>> useless. It's like your idea that the GC shouldn't be optional. Then all
>> library code needs to be written to work without the GC. It's the same
>> thing with runtime reflection.
>>
>
> This is a lib issue. phobos should provide a standard way to do
> compiletime -> runtime reflection so each lib doesn't need to provide
> its own way every time.

I think you're misunderstanding.

The point is that without built-in runtime reflection, reflection is only available for select classes that the programmer specifically asks to have RTTI for. This is useless. It doesn't enable discovery-based reflection at all, which is what makes runtime reflection in C#, Java, ... so useful.

-- 
- Alex

On 2012-04-16 13:34, deadalnix wrote:

> This is a lib issue. phobos should provide a standard way to do
> compiletime -> runtime reflection so each lib doesn't need to provide
> its own way every time.

Regardless of how the runtime reflection is generated, by a library or the compiler, it needs to be available to all types.

-- 
/Jacob Carlborg

On Monday, 16 April 2012 at 11:30:52 UTC, deadalnix wrote:
> Le 16/04/2012 11:25, Walter Bright a écrit :
>>
>> As for data that has no pointers, something has to indicate that. Of
>> course, another strategy is to allocate such data in separate pools. In
>> fact, that might be an excellent idea, as such pools would never have to
>> be read (i.e. swapped in, loaded into cache) during the mark/sweep process.
>
> That is exactly what I meant. Metadata about the block shouldn't be stored anywhere near the block, because it will behave horribly wrong when swap come into play. Metadata must be read and written when GC does its job, but the block itself doesn't require it.

+1
Agree, the metadata should be stored in a allocator private pool for cache reasons.

On 4/16/2012 9:40 AM, Jacob Carlborg wrote:
> Regardless of how the runtime reflection is generated, by a library or the
> compiler, it needs to be available to all types.

Why?

(I can see the point for a dynamic language, but not a static one.)

Le 16/04/2012 18:37, Walter Bright a écrit :
> On 4/16/2012 4:32 AM, deadalnix wrote:
>> Le 16/04/2012 11:25, Walter Bright a écrit :
>>> On 4/16/2012 2:05 AM, deadalnix wrote:
>>>> Having this template into object.d seems problematic to me. It is now
>>>> quite hard
>>>> to provide any custom GC implementation without messing with Druntime.
>>>>
>>>> Providing a user created GC should be as easy as possible.
>>>
>>> It's never going to be easy for anyone to just write their own GC,
>>> especially one that works better than one a lot of people have spent a
>>> lot of time on.
>>>
>>
>> I don't think this is easy. But Different GC have different impact on the
>> program. For instance, oracle's JVM provide you 4 different GC, that
>> you can
>> choose with different configuration parameters.
>
> Those are not user created GCs.
>
>
>> That is exactly what I meant. Metadata about the block shouldn't be
>> stored
>> anywhere near the block, because it will behave horribly wrong when
>> swap come
>> into play. Metadata must be read and written when GC does its job, but
>> the block
>> itself doesn't require it.
>
> I think the point is that it is not up to the compiler how this is done,
> but to the GC implementer.
>

The point was that putting this into object.d isn't, IMO, the best option to provide such a mecanism.

On Mon, Apr 16, 2012 at 09:53:34AM -0700, Walter Bright wrote:
> On 4/16/2012 9:40 AM, Jacob Carlborg wrote:
> >Regardless of how the runtime reflection is generated, by a library or the compiler, it needs to be available to all types.
> 
> Why?
> 
> (I can see the point for a dynamic language, but not a static one.)
[...]

Perhaps for dynamic loading of class objects?


T

-- 
Not all rumours are as misleading as this one.

On Apr 16, 2012, at 2:25 AM, Walter Bright wrote:

> On 4/16/2012 2:05 AM, deadalnix wrote:
>> Having this template into object.d seems problematic to me. It is now quite hard to provide any custom GC implementation without messing with Druntime.
>> 
>> Providing a user created GC should be as easy as possible.
> 
> It's never going to be easy for anyone to just write their own GC, especially one that works better than one a lot of people have spent a lot of time on.

What I've been going for is to have all functionality that requires knowledge of code generation, (most) platform specifics, etc, live in the compiler runtime portion of Druntime (i.e. in the "rt" package).  This is all stuff that the compiler writer knows by necessity, and the GC writer shouldn't be required to know it as well.

As for pointer maps, I think it's reasonable to establish a format that these will be made available to the GC, and for them to come from elsewhere in the runtime.  I realize that different GC implementations may prefer different formats, but hopefully we can settle on one that's pretty generally usable and efficient.  I'd really rather avoid expecting GC writers to know how to meta-process D types to statically generate this themselves.  Moving this into the GC would also eliminate the possibility of having the GC chosen at link-time, which is something that's currently still an option.

>> I think this is again solving an implementation issue by a language design decision. Ultimately the useless code bloat must be handled by the toolchain anyway.
> 
> We gotta work with what we have.
> 
>>> 6. I suggest the GCInfo pointer be stored at the end of the allocated block, as then it won't affect the alignment of the allocated data.
>> 
>> This very swap unfriendly. Many pages will have to be unswapped/swapped back in the marking process, even if it is 100% useless for data that doesn't contains pointers.
> 
> I think there's a misunderstanding. The GC allocates by powers of 2. So a 22 byte struct will be allocated in a 32 byte block, and the GCInfo pointer can go at the end of that. That will not cause swapping.
> 
> As for data that has no pointers, something has to indicate that. Of course, another strategy is to allocate such data in separate pools. In fact, that might be an excellent idea, as such pools would never have to be read (i.e. swapped in, loaded into cache) during the mark/sweep process.

This is obviously all for the current GC anyway.  Another implementation may be better off storing things elsewhere.

On 16-04-2012 20:02, Sean Kelly wrote:
> On Apr 16, 2012, at 2:25 AM, Walter Bright wrote:
>
>> On 4/16/2012 2:05 AM, deadalnix wrote:
>>> Having this template into object.d seems problematic to me. It is now quite hard
>>> to provide any custom GC implementation without messing with Druntime.
>>>
>>> Providing a user created GC should be as easy as possible.
>>
>> It's never going to be easy for anyone to just write their own GC, especially one that works better than one a lot of people have spent a lot of time on.
>
> What I've been going for is to have all functionality that requires knowledge of code generation, (most) platform specifics, etc, live in the compiler runtime portion of Druntime (i.e. in the "rt" package).  This is all stuff that the compiler writer knows by necessity, and the GC writer shouldn't be required to know it as well.
>
> As for pointer maps, I think it's reasonable to establish a format that these will be made available to the GC, and for them to come from elsewhere in the runtime.  I realize that different GC implementations may prefer different formats, but hopefully we can settle on one that's pretty generally usable and efficient.  I'd really rather avoid expecting GC writers to know how to meta-process D types to statically generate this themselves.  Moving this into the GC would also eliminate the possibility of having the GC chosen at link-time, which is something that's currently still an option.
>

I think we can safely settle on bitmaps for this. Most real world GCs use this kind of strategy.

>>> I think this is again solving an implementation issue by a language design
>>> decision. Ultimately the useless code bloat must be handled by the toolchain
>>> anyway.
>>
>> We gotta work with what we have.
>>
>>>> 6. I suggest the GCInfo pointer be stored at the end of the allocated
>>>> block, as then it won't affect the alignment of the allocated data.
>>>
>>> This very swap unfriendly. Many pages will have to be unswapped/swapped back in
>>> the marking process, even if it is 100% useless for data that doesn't contains
>>> pointers.
>>
>> I think there's a misunderstanding. The GC allocates by powers of 2. So a 22 byte struct will be allocated in a 32 byte block, and the GCInfo pointer can go at the end of that. That will not cause swapping.
>>
>> As for data that has no pointers, something has to indicate that. Of course, another strategy is to allocate such data in separate pools. In fact, that might be an excellent idea, as such pools would never have to be read (i.e. swapped in, loaded into cache) during the mark/sweep process.
>
> This is obviously all for the current GC anyway.  Another implementation may be better off storing things elsewhere.


-- 
- Alex

On 2012-04-16 18:53, Walter Bright wrote:
> On 4/16/2012 9:40 AM, Jacob Carlborg wrote:
>> Regardless of how the runtime reflection is generated, by a library or
>> the
>> compiler, it needs to be available to all types.
>
> Why?
>
> (I can see the point for a dynamic language, but not a static one.)

The standard example that comes back is serialization. That can be done without support for runtime reflection but not as good as with the support. As far as I know it's impossible to serialize through a base class reference without registering the subtype with the serializer, if runtime reflection isn't available.

-- 
/Jacob Carlborg