Talk:How is Aliasing Used in Systems Software/KennKnowles

From GradTurkey

[edit] Scientific Measurement

I don't follow exactly what you mean by scientific in your comment about measurement. I suppose that their hypothesis is that aliasing occurs in only a few ways; they then measured occurences and were able to define eight categories (out of thousands of occurences). Is this what you mean? I would have liked to have seen a bit more discussion on the false positives; can they use the eight aliasing patterns they found to flag the false positives as likely to be false? Did they use anti-annotations to cull the false positives from their results list?

--BoAdler 22:05, 17 April 2006 (PDT)

[edit] Linguistic Annotations

Is there any existing "linguistic model" for alias annotations? The one used in the paper seems to be fit to their data structure (the points-to graph), and not be designed for the end-programmer.

Along a related line, I think that languages have always benefited from incorporating data structures into the language (eg, arrays, strings, hash tables). Why aren't more data structures (eg, linked lists, trees) "standardized" into a language? Then object invariant style annotations could be just part of the definition, rather than depending on the programmer to remember and include them.

--BoAdler 22:14, 17 April 2006 (PDT)

Well, remember that linked lists are built in to ML and LISP, and basic trees are built into languages with algebraic datatypes (ML variants). I would say that the level of knowledge of the structures has to reach a point where a "default" implementation is sufficient for most purposes, or you'll get the Java standard library kind of nightmare. Hashtables are more appropriately placed in a library, since there is no real canonical form for them. The issue then is: How easily can we extend the syntax to make a library look built in, since things like perl hash syntax is nicer than "Hashtbl.get tbl foo".

I totally agree that the object invariants would be most appropriate "magicked" into datatypes, like hiding isorecursive types inside variants. I'm sure there are other examples too, where simply defining a type sets up the appropriate invariants.

--KennKnowles 12:20, 18 April 2006 (PDT)

Technically, "lists" are built in, and we don't know anything about the underlying implementation in ML or Lisp. They could be arrays, linked lists, or doubly linked lists (to name all the lists I can think of). On the one hand, this is good for abstraction; but the other hand says that sometimes we'd like more control than that. I guess that's where "C programmers rail against anything..." comes in. I really believe in abstraction... so maybe I'm wrong about control sometimes being important?

And what do you mean, there's no canonical form for hashtables? With respect to typing?

--BoAdler 15:09, 18 April 2006 (PDT)

[edit] Channels

Wow, that sounds very believable, that channels would reduce the I/O aliasing. But you make it sound like the I/O aliasing was always used in a multithreaded situation. Example 5 (the AES_encrypt example) is not multithreaded, however. Even if you somehow lock the variables (which is what I'm guessing you mean by "atomic"), the variables might not be directly aliased; if they only overlap, then your lock will have to work over ranges of memory. Am I misunderstanding your comment?

--BoAdler 22:26, 17 April 2006 (PDT)

After our discussion, I think I/O channels are more a product of manual memory management paradigms. The basic idea of passing in the location where the output from a function will be stored is non-issue in high-level languages. But then, for low-level programming, the invariant that parameters to a function ought to all be distinct pointers seems pretty reasonable and not terribly wasteful of space. I think there is probably an easy solution here, though C programers will rail against anything that doesn't let them do whatever they want :)

--KennKnowles 12:28, 18 April 2006 (PDT)

Is is true that passing "storage locations" goes away in high level languages? Because everything is functional, so you always return new copies of things? How do you write super-efficient network servers in a functional language? Can you? At the kernel level, doing network reads/writes are all about the "zero copy", and it seems like this should be true inside your application as well. Are low-level programmers just dinosaurs in this era of plenty (plenty cpu and ram, I mean).

--BoAdler 15:25, 18 April 2006 (PDT)