January 09, 2013
On 1/9/2013 12:28 AM, Mehrdad wrote:
> On Wednesday, 9 January 2013 at 08:14:35 UTC, Walter Bright wrote:
>> On 1/8/2013 11:42 PM, Mehrdad wrote:
>>> (True, it wouldn't give you the power of a systems language, but that's quite
>>> obviouly not my point -- the point is that it's a _perfectly possible_
>>> memory-safe language which we made, so I don't understand Walter's comment about
>>> a GC being "required" for a memory-safe language.)
>>
>>
>> The misunderstanding is you are not considering reference counting as a form
>> of GC. It is.
>
> So you would say that C++ code (which uses reference counting) uses garbage
> collection?

Yes, but it is not memory safe as C++ allows escapes from it.
January 09, 2013
On 1/9/2013 9:26 AM, Rob T wrote:
> You cannot guarantee memory safety with a GC either, depending on the definition
> of "memory safety".

GC is a necessary requirement for memory safety, but not sufficient.

> For example, you can still access deallocated memory by mistake,

If you're not playing with pointers, then this is a buggy GC.

> run out of
> memory due to accumulating persistent pointers left around by mistake,

Memory safety does not imply never running out of memory.

> or free memory that was not supposed to be freed by mistake.

Then it's a buggy GC.

> The GC implementation may
> fail due to bugs, deallocating live memory or failing to deallocate inactive
> memory.

Of course memory safety presumes a correctly implemented GC.

> The only thing a GC can do for you, is free up the programmer from the tedium of
> managing memory. It also allows constructs that otherwise would be very
> difficult or impractical to implement. The effect can be very positive, but
> there are no guarantees of memory safety.

This is incorrect - see above. A bug free GC, and not "cheating" in using it, guarantees memory safety. This is a big deal.

January 09, 2013
On 1/9/2013 10:32 AM, H. S. Teoh wrote:
> > does it guarantee memory safety?
>
> I think it does,

A GC is a necessary, but not sufficient, condition for memory safety.
January 09, 2013
On 1/9/2013 1:24 AM, Mehrdad wrote:
> The language need not give you any direct access to memory, making everything
> perfectly safe.

You can add a runtime check for every "pointer" access (much like what valgrind does), and abort on an invalid access. But that is not what memory safety is.

January 09, 2013
Am 09.01.2013 16:49, schrieb Andrei Alexandrescu:
> On 1/9/13 4:25 AM, Benjamin Thaut wrote:
>> The compiler is not shared-lib ready. At least not on windows. It does
>> not support exporting data symbols. E.g.
>>
>> export uint g_myGlobal;
>>
>> This is mostly a problem for "hidden" data symbols, like vtables, module
>> info objects, type info objects and other stuff D relies on.
>
> Are there bugzilla entries for this?
>
> Andrei

Yes its pretty old too. If you read through the discussion in the ticket and through the code Rainer Schuetze provided you will have a list of all the issues that need to be fixed for shared dlls to work:
http://d.puremagic.com/issues/show_bug.cgi?id=4071

In the following patch:
http://d.puremagic.com/issues/attachment.cgi?id=601&action=edit
Rainer Schuetze does manual patching for data symbols. But this is hardcoded to only work for his phobos shared dll. The function it is done in is called dll_patchImportRelocations. If I understand DLLs correctly this should usually be done by the import library that is created by the compiler for a shared dll. Maybe Rainer can shed some mor light on this.

Kind Regards
Benjamin Thaut
January 09, 2013
On Wednesday, 9 January 2013 at 18:46:53 UTC, Walter Bright wrote:
> GC is a necessary requirement for memory safety, but not sufficient.


Walter, would you mind explaining WHY it's "necessary"?


I just spent so many comments explaining why NO form of automatic memory management is required for guaranteeing memory safety () and then you reply and say "GC is a necessary requirement" and leave it at that.

See my comment here regarding handles, etc.:

http://forum.dlang.org/thread/mailman.232.1357570887.22503.digitalmars-d@puremagic.com?page=7#post-jimseaovuxmribkqbict:40forum.dlang.org
January 09, 2013
On 1/9/13 11:18 AM, Mehrdad wrote:
> On Wednesday, 9 January 2013 at 18:46:53 UTC, Walter Bright wrote:
>> GC is a necessary requirement for memory safety, but not sufficient.
>
>
> Walter, would you mind explaining WHY it's "necessary"?
>
>
> I just spent so many comments explaining why NO form of automatic memory
> management is required for guaranteeing memory safety () and then you
> reply and say "GC is a necessary requirement" and leave it at that.
>
> See my comment here regarding handles, etc.:
>
> http://forum.dlang.org/thread/mailman.232.1357570887.22503.digitalmars-d@puremagic.com?page=7#post-jimseaovuxmribkqbict:40forum.dlang.org

This is true but uninteresting. Entire classes of languages can be made memory-safe without garbage collection, such as many Turing incomplete languages, languages without referential structures, languages that don't expose pointers (such as your example) and more.

At the end of the day if references are part of the language and programs can build arbitrary reference topologies, safety entails GC.


Andrei


January 09, 2013
On Wednesday, 9 January 2013 at 18:46:53 UTC, Walter Bright wrote:
> On 1/9/2013 9:26 AM, Rob T wrote:
>> For example, you can still access deallocated memory by mistake,
>
> If you're not playing with pointers, then this is a buggy GC.

Yes you are correct. I was thinking of nullable references when I made that comment. When you dereference on a nulled reference, I suppose that's not really referencing deallocated memory. I'm not sure what exactly happens behind the scenes when you dereference a null pointer, but obviously bad things happen and it's not safe, also it is a memory related problem.

>
>> run out of
>> memory due to accumulating persistent pointers left around by mistake,
>
> Memory safety does not imply never running out of memory.

I did qualify what I said by mentioning that it depends on the definition of memory safety. According to my definition of memory safety, a memory leak is still a memory leak no matter how it happens. I can however see an alternate definition which is likely what you are suggesting, where so long as you are not accessing memory that is not allocated, you are memory safe. There must be more to it than that, so if you can supply a more correct definition, that would be welcome.

>> or free memory that was not supposed to be freed by mistake.
>
> Then it's a buggy GC.

Yes. The point however is that a GC can be buggy, so by having one kicking around guarantees nothing unless you can prove that the implementation is 100% correct.

I am reminded of the back up system that is less reliable than the medium it is supposed to be protecting, or the power backup supply that is less reliable than the main power grid.

My guess is that no one knows how good or bad a GC is relative to what a manual system can do. The claims are likely the result of anecdotal evidence alone. Has anyone actually done a scientifically valid study that shows that a GC implementation is statistically more reliable than a manual implementation?

Of course I understand that the lack of a scientific study proves nothing either way, I'm simply pointing out that we're likely making assumptions without any proof to back them up.

>> The GC implementation may
>> fail due to bugs, deallocating live memory or failing to deallocate inactive
>> memory.
>
> Of course memory safety presumes a correctly implemented GC.

Yes, of course, but this is a bit of a wild card since we probably have no proof that any given GC implementation will be correct.

>> The only thing a GC can do for you, is free up the programmer from the tedium of
>> managing memory. It also allows constructs that otherwise would be very
>> difficult or impractical to implement. The effect can be very positive, but
>> there are no guarantees of memory safety.
>
> This is incorrect - see above. A bug free GC, and not "cheating" in using it, guarantees memory safety. This is a big deal.

Yes and no. Yes if the definition excludes the ability to "leak memory" due to programmer error, meaning allocating but failing to deallocate - a GC cannot prevent this, only a programmer can. I figure your definition excludes this kind of programmer error, and that's OK with me.

I do however wonder about the ability to dereference null pointers, specifically pointers that are considered to be references. In D references are nullable, and I believe this is considered safe.

-rt
January 09, 2013
On Wednesday, 9 January 2013 at 12:25:08 UTC, Benjamin Thaut wrote:
>>
>> Walter claimed that compiler is shared-lib ready, it is just druntime
>> that is lacking. And he hasn't got knowledge to make it work on his own.
>>
>> Sean Kelly is out - he was Walter's bet to make it work.
>>
>> My hope was Martin Nowak, he was working on it but seems that he also
>> got busy with other stuff
>
> The compiler is not shared-lib ready. At least not on windows. It does not support exporting data symbols. E.g.
>
> export uint g_myGlobal;
>
> This is mostly a problem for "hidden" data symbols, like vtables, module info objects, type info objects and other stuff D relies on.
>
> Druntime on windows does already handle everything else pefectly (e.g. threads and TLS)
>
> Kind Regards
> Benjamin Thaut

http://dlang.org/phobos/core_runtime.html

I see library load and unload functions, although the required "dlsym" feature is absent. What's the status, does any of it actually work?

--rt
January 09, 2013
On Tuesday, 8 January 2013 at 23:04:48 UTC, Paulo Pinto wrote:
>
> Besides Web applications, I also took part in projects that ported high
> performance C++ daemons to Java.
>
Curious as to why? What was to be gained/overcome?

> These were servers doing millions of data processing manipulations per
> second of telecommunication data used in mobile networks.
>

Did it prove a worthwhile move?
Did the move relieve any issues with C++?
Was GC an issue in the end?

Thanks,
Dan