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
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
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
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
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
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
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
On 2012-04-16 18:37, Alex Rønne Petersen wrote:
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
On 04/16/2012 08:42 PM, Jacob Carlborg wrote:
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
On 4/16/2012 10:00 AM, deadalnix wrote:
The point was that putting this into object.d isn't, IMO, the best option to
provide such a mecanism.
I don't know of a better way to do it, nor do I think it matters if it is in
object.d or someothername.d.
On 4/16/2012 10:08 AM, H. S. Teoh wrote:
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
On 4/16/2012 11:02 AM, Sean Kelly wrote:
On Apr 16, 2012, at 2:25 AM, Walter Bright wrote:
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
On 4/16/2012 11:42 AM, Jacob Carlborg wrote:
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
On Sun, 15 Apr 2012 22:24:56 -0400, Walter Bright
newshou...@digitalmars.com wrote:
Just checked it in. Of course, it doesn't actually do precise GC, it is
just thrown over the wall for the library devs who are itching to get
started on it.
I added a getGCInfo() method to TypeInfo
On Mon, 16 Apr 2012 16:52:54 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
But we need to change the name early on to avoid conflicts. I don't
think a more generic name would be inappropriate, even if the GC is the
only client at first.
Should have said But we need to change
On 04/16/2012 10:51 PM, Walter Bright wrote:
On 4/16/2012 11:42 AM, Jacob Carlborg wrote:
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
On 4/16/12 1:31 PM, Alex Rønne Petersen wrote:
I think we can safely settle on bitmaps for this. Most real world GCs
use this kind of strategy.
This is a valid argument, but I should say it's very much worth
exploring techniques enabled by D specifically. Many unique and superior
D idioms
On 4/16/12 1:02 PM, Sean Kelly wrote:
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
On 4/16/12 3:49 PM, Walter Bright wrote:
Either the compiler has to generate the marking stuff, meaning that no
user designed GC is very practical, or it has to be generated at compile
time with a template, where a user designed GC can experiment with a
much wider range of possibilities without
On 4/16/2012 7:20 PM, Andrei Alexandrescu wrote:
The scheme Walter proposed has a lot of flexibility - it plants one pointer to
function per type. This is very flexible because that pointer could point to the
same function and use a bitmap-based scheme, or (as Walter proposed) point to
different
On Monday, 16 April 2012 at 16:53:53 UTC, 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
On 2012-04-15 04:11, Antti-Ville Tuunainen wrote:
On Saturday, 14 April 2012 at 19:17:02 UTC, Jacob Carlborg wrote:
There is: http://prowiki.org/wiki4d/wiki.cgi?GSOC_2012_Ideas
That's the ideas list for proposals. I was asking if anyone else applied
for GSoC using one of those.
Aha, I see.
Just checked it in. Of course, it doesn't actually do precise GC, it is just
thrown over the wall for the library devs who are itching to get started on it.
I added a getGCInfo() method to TypeInfo that returns an immutable(void)*. This
pointer can be anything - a pointer to data, to code
On 4/15/2012 7:24 PM, Walter Bright wrote:
3. Many types will follow similar patterns:
ptr .. int .. ptr .. int
ptr .. ptr
int .. ptr
I suggest that specializations exist for these to avoid generating innumerable
identical data structures or functions. In fact, if they are named with names
On 13 April 2012 17:25, Kagamin s...@here.lot wrote:
once you prefetched the function, it will remain in the icache and be
reused from there the next time.
All depends how much you love object orientation. If you follow the C++
book and make loads of classes for everything, you'll thrash the
On Sat, 14 Apr 2012 05:21:08 -0500, Manu turkey...@gmail.com wrote:
On 13 April 2012 17:25, Kagamin s...@here.lot wrote:
once you prefetched the function, it will remain in the icache and be
reused from there the next time.
All depends how much you love object orientation. If you follow
On Sunday, 8 April 2012 at 02:49:34 UTC, Andrei Alexandrescu
wrote:
Maybe we can get a GSoC project on that. We already have a
related proposal (lock-free GC).
That would be me.
Just though I should wave and say hello. Are there other GSoC
proposals in the GC area?
On 2012-04-14 19:46, Antti-Ville Tuunainen wrote:
On Sunday, 8 April 2012 at 02:49:34 UTC, Andrei Alexandrescu wrote:
Maybe we can get a GSoC project on that. We already have a related
proposal (lock-free GC).
That would be me.
Just though I should wave and say hello. Are there other GSoC
On Saturday, 14 April 2012 at 19:17:02 UTC, Jacob Carlborg wrote:
There is: http://prowiki.org/wiki4d/wiki.cgi?GSOC_2012_Ideas
That's the ideas list for proposals. I was asking if anyone else
applied for GSoC using one of those.
On Sunday, 8 April 2012 at 12:02:10 UTC, Alex Rønne Petersen
wrote:
This sounds important to me. If it is also possible to do the
work with
generated tables, and not calling thousands of indirect
functions in
someone's implementation, it would be nice to reserve that
possibility.
Indirect
On 13 April 2012 15:53, Kagamin s...@here.lot wrote:
On Sunday, 8 April 2012 at 12:02:10 UTC, Alex Rønne Petersen wrote:
This sounds important to me. If it is also possible to do the work with
generated tables, and not calling thousands of indirect functions in
someone's implementation, it
On 2012-04-13 16:54:28 +0300 Manu turkey...@gmail.com wrote:
While I'm at it. 'final:' and 'virtual' keyword please ;)
Hmmm, I thought we decided that was a good idea, anybody in the know if
this going to happen or not?
--
James Miller
On Friday, 13 April 2012 at 13:54:39 UTC, Manu wrote:
No other processors have branch prediction units anywhere near
the sophistication of modern x86. Any call through a function
pointer
stalls the pipeline, pipelines are getting longer all the time,
and PPC has
even more associated
Le 09/04/2012 23:27, Walter Bright a écrit :
On 4/9/2012 11:30 AM, deadalnix wrote:
In the other hand, TLS can be collected independently and only
influence the
thread that own the data. Both are every powerfull improvement, and
the design
you propose « as this » cannot provide any mean to
Le 10/04/2012 00:39, Manu a écrit :
It is, and I still don't follow. I can't imagine there are any indirect
function calls, except for the ones introduced by this proposal, where
you may register a function to mark the pointers in complex structs.
You seem to be suggesting that another one
On 4/10/12 3:03 AM, deadalnix wrote:
For every type, a function template (let's call it GCscan) will be
instantiated to scan it. This function can be ANY code. ANY code include
the possibility for GCscan!A to call GCscan!B directly, without going
back to GC main loop and indirect call. If
various schemes can be tried out without needing compiler
work.
I think this is an exciting idea, it will enable us to get a precise gc
by enabling people to work on it in parallel rather than serially
waiting for me.
I think this is a really good idea.
I would like to go further and propose
Le 08/04/2012 14:02, Alex Rønne Petersen a écrit :
On 08-04-2012 11:42, Manu wrote:
On 8 April 2012 11:56, Timon Gehr timon.g...@gmx.ch
mailto:timon.g...@gmx.ch wrote:
On 04/08/2012 10:45 AM, Timon Gehr wrote:
That actually sounds like a pretty awesome idea.
Make sure that the compiler does
this is an exciting idea, it will enable us to get a precise gc
by enabling people to work on it in parallel rather than serially
waiting for me.
This id a good idea. However, this doesn't handle type qualifiers. And
this is important !
D2 type system is made in such a way that most data are either thread
On 9 April 2012 21:20, deadalnix deadal...@gmail.com wrote:
Le 08/04/2012 14:02, Alex Rønne Petersen a écrit :
On 08-04-2012 11:42, Manu wrote:
On 8 April 2012 11:56, Timon Gehr timon.g...@gmx.ch
mailto:timon.g...@gmx.ch wrote:
On 04/08/2012 10:45 AM, Timon Gehr wrote:
That actually
Le 09/04/2012 20:33, Manu a écrit :
Eh?
Not sure what you mean. The idea is the template would produce a
struct/table of data instead of being a pointer to a function, this way
the GC could work without calling anything. If the GC was written to
assume GC info in a particular format/structure,
On 4/9/2012 11:30 AM, deadalnix wrote:
In the other hand, TLS can be collected independently and only influence the
thread that own the data. Both are every powerfull improvement, and the design
you propose « as this » cannot provide any mean to handle that. Which is a big
missed opportunity,
On 10 April 2012 00:06, deadalnix deadal...@gmail.com wrote:
Le 09/04/2012 20:33, Manu a écrit :
Eh?
Not sure what you mean. The idea is the template would produce a
struct/table of data instead of being a pointer to a function, this way
the GC could work without calling anything. If the
schemes can be tried out without needing compiler work.
I think this is an exciting idea, it will enable us to get a precise gc by
enabling people to work on it in parallel rather than serially waiting for me.
With __traits and such, I kind of always figured we'd go this way. There's
simply
this is an exciting idea, it will enable us to get a precise gc
by enabling people to work on it in parallel rather than serially
waiting for me.
That actually sounds like a pretty awesome idea.
On 04/08/2012 10:45 AM, Timon Gehr wrote:
That actually sounds like a pretty awesome idea.
Make sure that the compiler does not actually rely on the fact that the
template generates a function. The design should include the possibility
of just generating tables. It all should be completely
On 04/08/2012 10:45 AM, Timon Gehr wrote:
That actually sounds like a pretty awesome idea.
I understand that the stack will still have to be scanned
conservatively, but how does the scheme deal with closures?
On 4/8/2012 2:21 AM, Timon Gehr wrote:
On 04/08/2012 10:45 AM, Timon Gehr wrote:
That actually sounds like a pretty awesome idea.
I understand that the stack will still have to be scanned conservatively, but
how does the scheme deal with closures?
For now, just treat them conservatively.
On 8 April 2012 11:56, Timon Gehr timon.g...@gmx.ch wrote:
On 04/08/2012 10:45 AM, Timon Gehr wrote:
That actually sounds like a pretty awesome idea.
Make sure that the compiler does not actually rely on the fact that the
template generates a function. The design should include the
On 4/8/2012 11:21 AM, Timon Gehr wrote:
On 04/08/2012 10:45 AM, Timon Gehr wrote:
That actually sounds like a pretty awesome idea.
I understand that the stack will still have to be scanned
conservatively, but how does the scheme deal with closures?
I guess the compiler should generate an
On 08-04-2012 12:07, Rainer Schuetze wrote:
On 4/8/2012 11:21 AM, Timon Gehr wrote:
On 04/08/2012 10:45 AM, Timon Gehr wrote:
That actually sounds like a pretty awesome idea.
I understand that the stack will still have to be scanned
conservatively, but how does the scheme deal with
On 08-04-2012 11:42, Manu wrote:
On 8 April 2012 11:56, Timon Gehr timon.g...@gmx.ch
mailto:timon.g...@gmx.ch wrote:
On 04/08/2012 10:45 AM, Timon Gehr wrote:
That actually sounds like a pretty awesome idea.
Make sure that the compiler does not actually rely on the fact that
On 4/7/12 9:59 PM, Walter Bright wrote:
On 4/7/2012 7:58 PM, Chad J wrote:
Hey, that sounds awesome. I think I geeked out a bit.
Would this make it any easier to reference count types that can be
statically
proven to have no cyclical references?
It has nothing to do with reference counting
On 4/7/12 8:56 PM, Walter Bright wrote:
[snip]
I think this is an exciting idea, it will enable us to get a precise gc
by enabling people to work on it in parallel rather than serially
waiting for me.
I'm also very excited about this design, and will make time to help with
the library part
, it will enable us to get a precise gc by
enabling people to work on it in parallel rather than serially waiting for me.
On 4/7/2012 7:58 PM, Chad J wrote:
Hey, that sounds awesome. I think I geeked out a bit.
Would this make it any easier to reference count types that can be statically
proven to have no cyclical references?
It has nothing to do with reference counting that I can think of.
Hey, that sounds awesome. I think I geeked out a bit.
Would this make it any easier to reference count types that can be
statically proven to have no cyclical references?
On 4/7/12 9:49 PM, Andrei Alexandrescu wrote:
On 4/7/12 8:56 PM, Walter Bright wrote:
[snip]
I think this is an exciting idea, it will enable us to get a precise gc
by enabling people to work on it in parallel rather than serially
waiting for me.
I'm also very excited about this design
That sounds cool, perhaps people can have customizable GC for
specific applications?
Looking forward to D having a precise GC
http://d.puremagic.com/issues/show_bug.cgi?id=4719
nfx...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://d.puremagic.com/issues/show_bug.cgi?id=4719
Leandro Lucarella llu...@gmail.com changed:
What|Removed |Added
CC||llu...@gmail.com
http://d.puremagic.com/issues/show_bug.cgi?id=4719
Summary: Clean up associative array runtime interface to enable
precise GC
Product: D
Version: D1 D2
Platform: Other
OS/Version: All
Status: NEW
to
that. In fact, I think dsimcha has provided a way to have precise
scanning for heap-allocated types. I don't think a reasonably precise
GC is out of the question. However, it may be too much to require the
GC to do semantic analysis of enums for unions. Not impossible, but
probably
will -- contains
pointers or doesn't contain pointers. It doesn't mean we cannot add
to that. In fact, I think dsimcha has provided a way to have precise
scanning for heap-allocated types. I don't think a reasonably precise
GC is out of the question. However, it may be too much
This is just a small invention.
Enums can decrease the precision of the GC, because fields can be pointers or
values, an example:
enum NodeType { value, sum, product }
struct Node {
NodeType type;
union {
double val;
struct {
Node* left, right;
}
William T. Fnk:
This is a rather ridiculous way of emulating algebraic data types
I think algebraic data types in Haskell don't allow you to use for example
enums with no tags, where the tag is stored in the less significant bit of the
pointer that points to the enum.
And I think algebraic data
On Sun, 28 Mar 2010 09:40:10 -0300, bearophile bearophileh...@lycos.com
wrote:
This is just a small invention.
Enums can decrease the precision of the GC, because fields can be
pointers or values, an example:
enum NodeType { value, sum, product }
struct Node {
NodeType type;
bearophile Wrote:
William T. Fnk:
This is a rather ridiculous way of emulating algebraic data types
I think algebraic data types in Haskell don't allow you to use for example
enums with no tags, where the tag is stored in the less significant bit of
the pointer that points to the enum.
Robert Jacques:
This would require structs/arrays/etc to contain a header with a vtable,
so the GC could know what to do.
Do you mean a vtable pointer? Can you explain me why this is necessary?
remember, the GC allocates on
16-byte boundaries so each Node* actually has 4-bits (8 total)
On Sun, 28 Mar 2010 12:32:22 -0300, bearophile bearophileh...@lycos.com
wrote:
Robert Jacques:
This would require structs/arrays/etc to contain a header with a vtable,
so the GC could know what to do.
Do you mean a vtable pointer? Can you explain me why this is necessary?
Yes. What I
The problem is two-fold, there are newbie users in the community who have no
idea what an algebraic data type is. And then there are some more or less
arrogant (actually there's only one person whose arrogance exceeds anything
I've ever seen) language designers who recently studied the
Robert Jacques:
What I think you're forgetting is that all compile-time type info is lost at
runtime. [... etc]
Thank you very much for all your explanations, I didn't know that the situation
is so terrible. I suddenly like not-GC languages more :-)
I think the compilation of D code must build
William T. Fnk Wrote:
bearophile Wrote:
William T. Fnk:
This is a rather ridiculous way of emulating algebraic data types
I think algebraic data types in Haskell don't allow you to use for example
enums with no tags, where the tag is stored in the less significant bit of
the
a simple type info if you will -- contains pointers
or doesn't contain pointers. It doesn't mean we cannot add to that. In
fact, I think dsimcha has provided a way to have precise scanning for
heap-allocated types. I don't think a reasonably precise GC is out of the
question. However, it may
On Sun, 28 Mar 2010 13:50:20 -0300, bearophile bearophileh...@lycos.com
wrote:
Robert Jacques:
No, what you can't do is hide flags in high order bits or use tricks
like
XOR to store two pointers in a single field. The 4 low order bits are
fair
game:
This page:
types. I don't think a reasonably precise GC is out of
the question. However, it may be too much to require the GC to do
semantic analysis of enums for unions. Not impossible, but probably not
worth the effort and restrictions necessary.
-Steve
Also, don't forget that classes have
On 2009-04-13 20:33:53 +0200, Frits van Bommel
fvbom...@remwovexcapss.nl said:
Leandro Lucarella wrote:
Frits van Bommel, el 13 de abril a las 19:36 me escribiste:
Leandro Lucarella wrote:
Frits van Bommel, el 13 de abril a las 13:30 me escribiste:
Or you can pin anything that's referenced
Fawzi Mohamed, el 15 de abril a las 14:57 me escribiste:
Well, if it turns out to be a win, I'm sure we could put it into LDC.
DMD would be up to Walter.
and tango will also for sure welcome a new gc implementation.
Well, right now I'm working on a minimal, naive, fully documented GC
On Tue, 14 Apr 2009 06:04:01 -0400, Frits van Bommel
fvbom...@remwovexcapss.nl wrote:
Robert Jacques wrote:
On Mon, 13 Apr 2009 14:54:57 -0400, Frits van Bommel
fvbom...@remwovexcapss.nl wrote:
[snip]
An alternative to this is to encode the information in ClassInfo and
use
It's already
Robert Jacques wrote:
On Tue, 14 Apr 2009 06:04:01 -0400, Frits van Bommel
fvbom...@remwovexcapss.nl wrote:
Robert Jacques wrote:
it instead. (You'd have to create a fake ClassInfo for structs and
arrays.) Then the GC only has to track the start of each object (i.e.
the beginning of a block
On Tue, 14 Apr 2009 11:34:05 -0400, Frits van Bommel
fvbom...@remwovexcapss.nl wrote:
Robert Jacques wrote:
On Tue, 14 Apr 2009 09:27:09 -0400, Frits van Bommel
fvbom...@remwovexcapss.nl wrote:
Robert Jacques wrote:
On Tue, 14 Apr 2009 06:04:01 -0400, Frits van Bommel
Sean Kelly wrote:
Leandro Lucarella wrote:
But right now gc_malloc() doesn't take any TypeInfo argument. I can't see
where I can get the TypeInfo in the first place =/
The call would have to be modified. Right now the best you can do is
pass BlkAttr.NO_SCAN. And storing a pointer per block
201 - 283 of 283 matches
Mail list logo
