On Tue, Jul 30, 2013 at 1:09 PM, David Jeske <[email protected]> wrote:
> On Tue, Jul 30, 2013 at 11:44 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> What I *have* said is that the introduction of unmanaged code is >> categorically unacceptable. >> > > Even in understanding this, I don't fully understand the boundaries of it. > > Perhaps it would be useful to be explicit. Where the unsafe code is > allowed and who is allowed to write it? > > The runtime itself must do unsafe things, so certainly that code is > unsafe. > Actually, that's a commonly accepted assertion whose truth isn't at all evident. > Assuming a traditional kernel (for now), the syscall interface is unsafe, > so the stdlib wrappers around those calls must be unsafe. Is that the only > unsafe code allowed? As in, no JNI/PInvoke/FFI, no leverage of legacy code, > no restricted unsafe keywords.. ? > Ultimately, I really *would* like to reject JNI/PInvoke/FFI. While we need to accept unsafe code, there is a problem in C#/CLR that the *meaning* of "unsafe" isn't very clear. I understand that we need to support legacy codes transitionally. Failing a formal verification of safety, I view every single line of that unsafe code as an active hazard to the general public. > ...you persistently neglect consideration of the overheads of malloc/free >> in your discussions. GC may still lose the performance debate, but if we're >> going to argue it on those grounds, let us do so honestly. >> > > This is an interesting point. I don't think I do at all. If I do, I would > certainly like to know why and fix it! Please let me know what part of the > position below you think is unfairly considering malloc/free costs! > When I say that you fail to consider it, what I mean is that you constantly trot out numbers about GC overheads and routinely fail to speak about the corresponding malloc/free overheads in the same cases. That, and I think your GC overhead numbers are pretty much pulled out of your ass :-) but that at least has the merit of tradition in these sorts of discussions. If you are going to talk about the CPU and memory overhead of GC, you also need to quantify and compare the CPU and memory overhead of malloc/free. Without that, it's all an exercise in strong assertion. > (2) If we step aside responsiveness (assuming C4 or some sufficiently > smart no-world-stop solution), then we're talking about CPU efficiency. > And possibly memory usage overheads as well. > ... true. And for many applications it is not. My subjective opinion is > that there are more applications stuck in unsafe land because of GC > responsiveness problems than CPU or memory overhead. Since you assert $100 > more in memory (or CPU) should be irrelevant costs to us, do you agree > Responsiveness is the main problem in today's GC implementations? > Given a better-than-dismal GC, I think it's a significant problem in a small number of specialized applications. > >> GC (with world-stop) has notably worse responsiveness than >>> manual-collection. This is because the timing of GC can not be controlled >>> while the timing of manual collection can be precisely controlled. >>> >> >> Because it is inadequately qualified, this statement is false. >> > > ...yes! let me fix it.. "for many applications, especially those that are > directly interacting with end-users, via GUI systems, running on the > client, driving the pixels, and pixel motion, and rendering.".. Lots of > qualification. I think that's still a pretty good number apps. > Funny, because empirically *none* of those issues were concerns when I had a Dandetiger in my office at SGI, and they certainly weren't significant in Smalltalk-based systems. But more importantly, I think you are stuck arguing on a single criterion, and I think other criteria are far more important. I'm *completely* comfortable with not supporting microsecond trading applications, and I'm reasonably confident, given some conversations with Tim Sweeney, that the game examples you cite can be solved. > >> I'm much less interested in the performance and user perception of >> individual applications, and much more interested in systemic effects. If >> asked "will you use this slower program rather than that faster program", >> the answer is obviously no. If asked "will you accept a requirement for >> $100 more memory in order to dramatically improve your system security and >> stop worrying about many classes of attacks" the answer really should be >> yes. >> > > We agree 100% here. The practical trouble I'm having is that there is no > amount of memory or CPU I can reasonably get users to buy to stop end-user > apps from pausing while written in managed code. > You keep asserting this. Please go re-read the C4 papers. I agree wholeheartedly that non-current collectors are only practical when the live set is small enough to render the pause times insignificant. I further agree that there are subprograms where you really don't want to pause. A challenge with such subprograms is that GC can be induced by an unrelated thread, and the global coordination that is required for naive multi-threaded collection can become a problematic source of pauses - though this really *may* be a place where regions can help. > WIth no sarcasm intended, if you really believe I am pursuing the wrong >> path, you can and should start a project to address the things that you >> believe are important. > > > Of course you are pursuing a great path, or I wouldn't be here! > Fair enough. But just to make sure I wasn't mis-read, I really *wasn't* trying to be sarcastic. You're pushing very hard on issues that I believe cannot be addressed successfully in isolation, but they are important issues, and I have a finite supply of attention. If I don't prioritize something that is important to you, that doesn't mean I think it's unimportant. All it means is that there is only so much I can do at once. A really interesting alternate path would be to design CLI/CLR' and proceed from there. The three interesting questions in that would appear to be: (1) what does the type system look like, (2) what concurrency deficiencies do we want to resolve, and how, (3) what does the new GC look like. The main thing that stops me from going there right off is that I think that type system is informed by our HLL type system requirements. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
