On 2014-02-04 06:50:51 +0000, Walter Bright said:

> On 2/3/2014 1:42 PM, Shammah Chancellor wrote:
>> It's also probably
>> possible to create a drop-in replacement for the GC to do something else.
> 
> It certainly is possible. There's nothing magic about the current GC, it's just library code.

Is it possible that we add some additional functionality to the GC API so that it could do ARC?  I took a look at it, and it seems that right now, there'd be no way to implement ARC.

-S.

On Tuesday, 4 February 2014 at 12:03:31 UTC, Frustrated wrote:
[snip]
> It would be nice if one could simply write some allocator, drop
> it into D, and everything work out dandy. e.g., I want to try out
> a new super fast AGC like metronome GC, I write the code for it,
> tell D to use it, and then reap the benefits.

You can write your own GC now and drop it in, we did as an experiment.

If you're talking about a dropping in an allocator that is another matter, an allocator is not a GC.


Cheers,
ed

On 2014-02-04 04:26:22 +0000, Walter Bright <newshound2@digitalmars.com> said:

> On 2/3/2014 8:17 PM, Michel Fortin wrote:
>> That's not the case for nullable.
> 
> Yes, it is. If the function accepts a pointer to S and returns a pointer to S.f, then a null pointer in means a null pointer out, and a completely different type.

For that to happen you'd have to have a function like this one:

	class MyObject { OtherObject value; }

	OtherObject? foo(MyObject? o)
	{
		if (o)
			return o.other;
		else
			return null;
	}

The corresponding not-nullable version would be like that (notice the efficiency gain):

	OtherObject foo(MyObject o)
	{
		return o.other; // no need to check for null here
	}

Honestly, I don't think writing accessors that check for null is that common, except to detect null pointers passed in error because of the lack of static checking. In general for an accessor it's better to let the parent function check for null and only implement the later version of the accessor. The parent function can do one null check before calling all the accessors it wants, and accessors don't have to check for null. You lose that efficiency if each accessors has to check for null.

For the rare cases where you actually want both versions to work, you can write them twice or use a template (except in a virtual context), and in both cases you keep the efficiency of not checking for null when the argument is not nullable.

In any case, I have yet to understand why @nullable as a storage class would be any better. How do you solve that problem with a storage class?

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On Tuesday, 4 February 2014 at 11:57:25 UTC, Paulo Pinto wrote:
> On Tuesday, 4 February 2014 at 11:13:03 UTC, Don wrote:

>> Yeah, I dunno what "systems language" means really.
>
> For me it means you can write an OS with it, even if some tiny parts require the use of Assembly glue.


Pretty close to my definition, but I would add:

- you should be able to write a performant OS with it
- you should be able to use all core language features when doing so
- the mapping to hardware should be obvious
- thus the runtime should be transparent/easy to grasp

Basically I think a system level language should provide a minimal library and runtime that you can extend to a OS-level library that you use for implementing all services on your OS.

I think GC+Phobos should be an extension of such a minimal set up.

---

I don't think ARC is needed for D, because I think you use RC only when needed when writing latency sensitive code and use primarily other strategies (unique pointers, embedded objects etc).

I do think that interop with C++ is a good strategy. Language level support for C++11 pointer types would be a good addition now that they are being used quite extensively. Interop with C++ is more important than Objective-C.

Having a system library core that is GC free would be nice. I think this should be done on the name space level. I.e. having one optimized "core" section that is 100% GC free and one more extensive "std" section that requires GC to be available.

I don't think it is realistic to have all libraries being non-GC. It is better to have useful libraries that are somewhat inefficient than not having them due to complexity issue.

It is better to have a very easy to use and extensible to XML DOM library than to have a more obfuscated and less extensible XML DOM library without GC. But the XML parser library should be GC free.

On Tuesday, 4 February 2014 at 12:18:22 UTC, ed wrote:
> On Tuesday, 4 February 2014 at 12:03:31 UTC, Frustrated wrote:
> [snip]
>> It would be nice if one could simply write some allocator, drop
>> it into D, and everything work out dandy. e.g., I want to try out
>> a new super fast AGC like metronome GC, I write the code for it,
>> tell D to use it, and then reap the benefits.
>
> You can write your own GC now and drop it in, we did as an experiment.
>
> If you're talking about a dropping in an allocator that is another matter, an allocator is not a GC.
>
>
> Cheers,
> ed

Yes, you can do a lot with D, even rewrite D runtime to remove GC
dependent stuff, or write your own Phobos library. It is not easy
and D is not *designed* to do that.

AGC is about automatic deallocation so you don't have to *free*
the memory you allocate. To do this you have to allocate through
the GC so it knows when you allocate. So a GC is an allocator.

Regardless, I would simply like to have, as I'm sure many would,
the ability to set how D handles memory.

1. No memory management at all - Fast as possible. No memory is
ever free'ed. Similar to how DMD works.

2. Manual memory management - Pretty fast but old school.
Predictable but error prone. Different allocating schemes for
dealing with efficiency. Some apps require this to be performant.

3. Automatic memory management - Easy to use = Lazy mentality.
Safer. Most apps would not need anything more than this.

4. Combination of the above - The hard part. How to make all this
stuff plug and play, work well together, easy to use, etc...




Right now, D basically only has #3. Some have worked D to use 2.
std.allocators goes a long way in the right direction as does
std.allocators.gc. All I'm wanting is a unified way to use it all
and to get D and phobos off the hard dependence of the GC.

>
> I've seen you say more than once that you can't bond with the GC, and believe me I understand, if you search back through the forums, you'll find one of the first things I did when I got here was complain about the GC. But what you're saying is "I can't bond with this horrible GC so we need to throw it out and rebuild the compiler to support ARC." All I am saying is "I can't bond with the horrible GC, so why don't we make a better one, that doesn't ruin responsiveness, because I've seen it done in other places and there is no technical reason D can't do the same, or better."

There are lots of technical reasons why D's GC is just the way it is and why Java and C# can do better. They have been enumerated in this forum a lot of times, you simply chose to ignore them:

1. D doesn't restrict pointers, interior pointers abound especially thanks to the design of slices. Interior pointers are a problem for every high performance GC algorithm I'm aware of.
2. D's design doesn't easily allow for read or write barriers in general. You simply cannot make a GC behave without barriers.
3. Unions cause some (minor) problems.

In general the type system doesn't distinguish between GC'ed memory and manually managed memory at all.


> Now that I've started to read the GC Handbook I am starting to suspect that using D, there might be a way to create a completely pause-less GC. Don't hold me too it, I don't know enough yet, but D has some unique capabilities that might just make it possible.

That's just bullshit. The opposite is true: Of the big players D is easily the language that is most hostile to an efficient GC implementation.

On Tuesday, 4 February 2014 at 02:59:11 UTC, Andrei Alexandrescu wrote:
> On 2/3/14, 5:51 PM, Manu wrote:
>> I'd have trouble disagreeing more; Android is the essence of why Java
>> should never be used for user-facing applications.
>> Android is jerky and jittery, has random pauses and lockups all the
>> time, and games on android always jitter and drop frames. Most high-end
>> games on android now are written in C++ as a means to mitigate that
>> problem, but then you're back writing C++. Yay!
>> iOS is silky smooth by comparison to Android.
>
> Kinda difficult to explain the market success of Android.
>
> Andrei

Market success is probably 10% about technology and 90% about PR, filling the niche, finding right time etc.

There is a lot of discussion ongoing about ARC vs GC but in practice forcing either of those is unacceptable. Language that is strongly coupled with hard-coded memory model will inevitably fail in some domain.

For me perfect solution would have been to use an allocator concept as language basis instead and let you chose any conformant allocator for built-in language features. With both GC and ARC available in Phobos / druntime.

Bottom-Up design is simply superior to Top-Down when it comes to tools.

On Tuesday, 4 February 2014 at 12:46:58 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 4 February 2014 at 11:57:25 UTC, Paulo Pinto wrote:
>> On Tuesday, 4 February 2014 at 11:13:03 UTC, Don wrote:
>
>>> Yeah, I dunno what "systems language" means really.
>>
>> For me it means you can write an OS with it, even if some tiny parts require the use of Assembly glue.
>
>
> Pretty close to my definition, but I would add:
>
> - you should be able to write a performant OS with it
> - you should be able to use all core language features when doing so
> - the mapping to hardware should be obvious
> - thus the runtime should be transparent/easy to grasp
>
> Basically I think a system level language should provide a minimal library and runtime that you can extend to a OS-level library that you use for implementing all services on your OS.
>
> I think GC+Phobos should be an extension of such a minimal set up.
>
> ---
>
> I don't think ARC is needed for D, because I think you use RC only when needed when writing latency sensitive code and use primarily other strategies (unique pointers, embedded objects etc).
>
> I do think that interop with C++ is a good strategy. Language level support for C++11 pointer types would be a good addition now that they are being used quite extensively. Interop with C++ is more important than Objective-C.
>
> Having a system library core that is GC free would be nice. I think this should be done on the name space level. I.e. having one optimized "core" section that is 100% GC free and one more extensive "std" section that requires GC to be available.
>
> I don't think it is realistic to have all libraries being non-GC. It is better to have useful libraries that are somewhat inefficient than not having them due to complexity issue.
>
> It is better to have a very easy to use and extensible to XML DOM library than to have a more obfuscated and less extensible XML DOM library without GC. But the XML parser library should be GC free.


In Oberon and Modula-3's control over GC tends to be a  bit easier than D's current design, because of a few points:

- No implicit allocations outside NEW
- No closures
- You can use untraced pointers in unsafe modules.

However it would be nice to know if anyone here has real life experience with Lisp Machines and how was their performance.

--
Paulo

On Tuesday, 4 February 2014 at 13:18:51 UTC, Dicebot wrote:
> There is a lot of discussion ongoing about ARC vs GC but in practice forcing either of those is unacceptable. Language that is strongly coupled with hard-coded memory model will inevitably fail in some domain.
>
> For me perfect solution would have been to use an allocator concept as language basis instead and let you chose any conformant allocator for built-in language features. With both GC and ARC available in Phobos / druntime.
>
> Bottom-Up design is simply superior to Top-Down when it comes to tools.

And who could disagree with that? Yet we have many ;/

I guess it's all about fear. There are people that use the GC and
think they will never need more. They think "changing it" will
cause them to have to learn something new, which is difficult for
them. Hence they rather keep their world the same than allow
someone else the satisfaction of making things better for them.
What they don't realize is that their world won't change... so
maybe it's a bit of ignorance too?