View mode: basic / threaded / horizontal-split · Log in · Help
January 10, 2013
Re: manual memory management
On Thu, Jan 10, 2013 at 01:50:28AM +0100, Adam D. Ruppe wrote:
> On Thursday, 10 January 2013 at 00:18:26 UTC, Walter Bright wrote:
> >And that is not dereferencing null, it is dereferencing 0x1000000.
> 
> Yes, but it is worth noting that dmd will happily compile that code,
> even if marked @safe - just because the pointer on the language
> level is null doesn't mean it is memory safe at the assembly level.
> 
> the generated code with @safe is still just what we'd expect too:
>    3:   31 c0                   xor    eax,eax
>    5:   c7 80 00 00 10 00 0a    mov    DWORD PTR [eax+0x100000],0xa

Yeah that's exactly what I was thinking too. To DMD, it's a null pointer
dereference. But actually, it's dereferencing something else, because
x.fieldName is, in general, *not* null when x is null.

Hmm. This looks like another hole in SafeD? Unless null pointer checks
are inserted. (The checks have to be made on x, not x.fieldName, of
course.)


T

-- 
Notwithstanding the eloquent discontent that you have just respectfully
expressed at length against my verbal capabilities, I am afraid that I
must unfortunately bring it to your attention that I am, in fact, NOT
verbose.
January 10, 2013
Re: manual memory management
On Thursday, 10 January 2013 at 01:10:06 UTC, H. S. Teoh wrote:
> On Thu, Jan 10, 2013 at 01:50:28AM +0100, Adam D. Ruppe wrote:
>> On Thursday, 10 January 2013 at 00:18:26 UTC, Walter Bright 
>> wrote:
>> >And that is not dereferencing null, it is dereferencing 
>> >0x1000000.
>> 
>> Yes, but it is worth noting that dmd will happily compile that 
>> code,
>> even if marked @safe - just because the pointer on the language
>> level is null doesn't mean it is memory safe at the assembly 
>> level.
>> 
>> the generated code with @safe is still just what we'd expect 
>> too:
>>    3:   31 c0                   xor    eax,eax
>>    5:   c7 80 00 00 10 00 0a    mov    DWORD PTR 
>> [eax+0x100000],0xa
>
> Yeah that's exactly what I was thinking too. To DMD, it's a 
> null pointer
> dereference. But actually, it's dereferencing something else, 
> because
> x.fieldName is, in general, *not* null when x is null.
>
> Hmm. This looks like another hole in SafeD? Unless null pointer 
> checks
> are inserted. (The checks have to be made on x, not 
> x.fieldName, of
> course.)
>

That is exactly why my NPE proposal do trigger on other address 
that 0. Still, it require to add check for big objects (or high 
indices in arrays).
January 10, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 23:53:40 UTC, Andrei Alexandrescu 
wrote:
> On 1/9/13 3:38 PM, Paulo Pinto wrote:
>> My favorite GC book:
>>
>> http://www.amazon.com/Garbage-Collection-Algorithms-Automatic-Management/dp/0471941484/ref=sr_1_2?s=books-intl-de&ie=UTF8&qid=1357774599&sr=1-2
>
> I own the more recent edition and made a pass through it but I 
> don't think it discusses safety that much. Any chapter I should 
> be looking at?
>
> Andrei

No really. It is my favorite GC book, because it is the only one 
I know where so many GC algorithms get described, but I haven't 
read it in depth to be able to assert how safety is described.

And here is another one about real time GC that I own, although 
it focus on JVMs:

http://www.amazon.com/Realtime-Collection-Oriented-Programming-Languages/dp/3831138931/ref=sr_1_1?ie=UTF8&qid=1357806697&sr=8-1&keywords=Fridtjof+Siebert
January 10, 2013
Re: manual memory management
On Thursday, 10 January 2013 at 00:50:30 UTC, Adam D. Ruppe wrote:
> On Thursday, 10 January 2013 at 00:18:26 UTC, Walter Bright 
> wrote:
>> And that is not dereferencing null, it is dereferencing 
>> 0x1000000.
>
> Yes, but it is worth noting that dmd will happily compile that 
> code, even if marked @safe - just because the pointer on the 
> language level is null doesn't mean it is memory safe at the 
> assembly level.
>
> the generated code with @safe is still just what we'd expect 
> too:
>    3:   31 c0                   xor    eax,eax
>    5:   c7 80 00 00 10 00 0a    mov    DWORD PTR 
> [eax+0x100000],0xa

That brings us to another point.

It does not matter how safe a language might be, if someone can 
change the assembly then everything is possible.

Or am I going too off-topic?
January 10, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 22:29:36 UTC, Jonathan M Davis 
wrote:
> On Wednesday, January 09, 2013 14:14:15 Walter Bright wrote:
>> On 1/9/2013 1:23 PM, Mehrdad wrote:
>> > And are you considering reference counting to be garbage 
>> > collection like
>> > Walter does,
>> 
>> It's not something I came up with. It is generally accepted 
>> that ref
>> counting is a form of garbage collection.
>
> I definitely would never have referred to reference counting as 
> garbage
> collection and find it quite odd that it would be considered to 
> be such, but
> Wikipedia does indeed list it as being a form of garbage 
> collection:
>
> http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
>
> So, it's backing you up in your usage of the term.
>
> - Jonathan M Davis

This is what I was saying all along, in CS GC books reference 
counting is usually introduced as poor man's GC solution. As the 
most simple way to implement some kind of automatic memory 
management, specially in memory constrained devices at the 
expense of execution speed.

--
Paulo
January 10, 2013
Re: manual memory management
On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright wrote:
> On 1/7/2013 3:11 PM, H. S. Teoh wrote:

> One thing I'd add is that a GC is *required* if you want to 
> have a language that guarantees memory safety, which D aims to 
> do. There's an inescapable reason why manual memory management 
> in D is only possible in @system code.

I think that, at least for @system code (or invent another @), D 
programs should be able to require only GC-free code (forbiding, 
for example, features requiring GC).

I do some Linux kernel code. For most of it, I find it quite 
difficult to rely on the GC if I would use D instead of C.

One specific question: when handling an interrupt in Linux 
kernel, you are not allowed to sleep. But I think GC (and 
GC-triggering features) will sleep. So their use should be 
forbidden.

The main difference wrt to C programming for kernel: in C, to 
avoid sleeping, you need to stay away of some kernel/library 
functions; in D, you need to stay away of some language features.

Is one thing to avoid using specific functions. Is another thing 
to avoid using specific language constructs.
January 10, 2013
Re: manual memory management
On Tuesday, 8 January 2013 at 23:10:01 UTC, Paulo Pinto wrote:
> Am 08.01.2013 17:12, schrieb Benjamin Thaut:
>> Am 08.01.2013 16:46, schrieb H. S. Teoh:
> Without dismissing your experience in game development, I think 
> that your experience was spoiled by D's GC quality.
>
> After all, there are Java VMs driving missiles and ship battle 
> systems, which have even higher timer requirements.

Yes, but they are relying on specific, very special constructs of 
Java, such as:

http://www.rtsj.org/specjavadoc/javax/realtime/NoHeapRealtimeThread.html
http://www.rtsj.org/specjavadoc/javax/realtime/RealtimeThread.html

which have very little, if any, to do do with regular Java. BTW, 
since when a Java programmer should be concerned about... heap? 
What's that? malloc()?

The fact that it uses the same syntax as Java, simply does not 
mae it Java, at least in the (regular) JVM sense.
January 10, 2013
Re: manual memory management
On Thursday, 10 January 2013 at 09:05:53 UTC, eles wrote:
> On Tuesday, 8 January 2013 at 23:10:01 UTC, Paulo Pinto wrote:
>> Am 08.01.2013 17:12, schrieb Benjamin Thaut:
>>> Am 08.01.2013 16:46, schrieb H. S. Teoh:
>> Without dismissing your experience in game development, I 
>> think that your experience was spoiled by D's GC quality.
>>
>> After all, there are Java VMs driving missiles and ship battle 
>> systems, which have even higher timer requirements.
>
> Yes, but they are relying on specific, very special constructs 
> of Java, such as:
>
> http://www.rtsj.org/specjavadoc/javax/realtime/NoHeapRealtimeThread.html
> http://www.rtsj.org/specjavadoc/javax/realtime/RealtimeThread.html
>
> which have very little, if any, to do do with regular Java. 
> BTW, since when a Java programmer should be concerned about... 
> heap? What's that? malloc()?

Any developer worth its salt should worry how their application 
makes use of the available resources.

>
> The fact that it uses the same syntax as Java, simply does not 
> mae it Java, at least in the (regular) JVM sense.

The JVM is just a possible implementation of Java, the language.

It was quite an unfortunate decision for the Sun marketing team 
to call the language and the VM the same name.

This always ends up in lots of confusions when people consider 
the JVM to be the only way to execute Java.

Usually only developers with compiler design background end up 
making the difference, as languages and implementations are quite 
two different issues.


--
Paulo
January 11, 2013
Re: manual memory management
On Thursday, 10 January 2013 at 08:38:18 UTC, Paulo Pinto wrote:
>
> This is what I was saying all along, in CS GC books reference 
> counting is usually introduced as poor man's GC solution. As 
> the most simple way to implement some kind of automatic memory 
> management, specially in memory constrained devices at the 
> expense of execution speed.
>
> --
> Paulo

This is likely a long shot (and may have already been proposed), 
but what the heck: If reference counting is considered to be 
garbage collection, and D is a garbage collected language, then 
can the current form of GC be replaced with a reference counted 
version that is fully automated, or does something like that 
always have to be manually hand crafted because it is not generic 
enough to fit in?

BTW: I did read through the responses concerning by past posts 
about the GG and memory safety, and I agree with those responses. 
I now have a much better understanding of what is meant by 
"memory safety", so thanks to everyone who took the time to 
respond to my ramblings, I've learned something new.

--rt
January 11, 2013
Re: manual memory management
On 1/10/2013 4:05 PM, Rob T wrote:
> This is likely a long shot (and may have already been proposed), but what the
> heck: If reference counting is considered to be garbage collection, and D is a
> garbage collected language, then can the current form of GC be replaced with a
> reference counted version that is fully automated,

Yes, but you'd have to rework the semantics of array slices, function closures, 
etc., to add in the reference counts.
11 12 13 14 15 16
Top | Discussion index | About this forum | D home