On Tue, Jul 16, 2013 at 12:50 PM, Jonathan S. Shapiro <[email protected]>wrote:
> Examination of such "large" programs tends to reveal that the overwhelming > majority of long-lived data consists of value types. > > The app scenario that is problematic is applications that involve large > numbers of long-lived objects that (a) contain references and (b) those > references are mutated with a rate of change above some hard-to-specify > threshold [potentially creating garbage]. Actually, it's not the rate of > mutation per se. It's the rate at which mutations cause objects to become > orphaned, which is kind of hard to understand. Long lived value-type objects do not need to contain pointers to be a problem, they merely need to be small and referenced by pointers. Also, keep in mind your earlier observation, that we're not strictly talking about pointer-to-value fraction, but the number of pointer-polluted-cachelines. i7 cacheline size is 64bytes. A single 8byte pointer in a mixed pointer/data struct will pollute another 56bytes of cacheline as far as pointer-tracing performance is concerned. While I'm sure there are some large-heap programs where <15% of cachelines are pointer polluted. I'm quite sure there are many others where >70% of cachelines are pointer-polluted. Let's look at a simple application subsystem which I'm sure you will agree is *commonly*used* in large programs, and which spans both of these conditions -- the simple LRU cache. An LRU cache with small value sizes will have a very large percentage of pointer-polluted-cachelines, while one with very large value sizes will have a very small percentage of pointer-polluted cachelines. This one of the main reasons large-heap webserver caches are pushed out of JVM processes into C processes like memcached. 3. Shift to hybrid management strategies, whether those are counted or > owned or linear or what have you. > We agree here. -- AFAIK, non-world-stop typesafe collection for the simple LRU cache can not be solved by regions, linear-types, or static-analysis. It requires either non-world-stop GC, or ARC (with or without GC-like cycle finding). I'd personally like to see more production implementations of ARC + non-world-stop cycle finding -- because I think even given C4, there are certain applications/subsets where this approach is superior. Regardless, I do think it's reasonable to provide hybrid ARC+GC schemes to solve these problems (a solution we do not have today in CLR/JVM). ---- While I believe the LRU cache is a nice simple strawman to discuss the problem, many applications have very intermixed pointers and data -- and as a result exhibit very high polluted cacheline fraction. What data do you think would demonstrate to you that these programs exist? (not saying I have the time or interest to generate such data) One could probably do automated static analysis of open-source C/C++ type definitions across a few large open-source applications, which combined with a bit of type-frequency estimation, could provide us an estimated polluted cacheline percentage for those applications. We could probably even compute an estimated stop-the-world pause time given a specific heap size. (I'd sponsor such research) This makes me wonder if perhaps we have under-exploted schemes to automatically maximize the pointer-efficiency of pointer-polluted-cachelines. There might be un-obvious methods to try here. For example, a 64byte structure with only one 8 byte pointer could be duplicated into an "multi-bin" version of the same structure... basically 7-copies of the same structure merged, with the 7 pointers located in one cacheline, along with tag-bits to indicate used/free/gc flags for each of the 7 value-type bins -- which would be located contiguously afterwords. This would provide better GC tracing cacheline efficiency for the struct while keeping access to any one of the bins within reasonable L2 proximity. Or not, just thinking out loud there. With respect and humor, kicking straw dogs seems a saner approach than >> legistlation to ban use of tools that meet there needs without proof the >> alternatives are sufficient. >> > > Part of the purpose of taxes and regulation is to raise the cost of > socially destructive behavior until its transfer costs are accounted for. > Ideally, forcing the prices to match the real societal costs leads to > invention of better solutions. At minimum, it forces people to look real > hard for better solutions and minimize use of bad ones. > An interventionist, I see. I accept the validity of the strategy. I just don't trust anyone's ability to assign appropriate costs. It's very easy for efforts like this to intentionally or accidentally assign artificial costs which are not truly aligned with social good. Look at the way entrenched fossil energy taxes and credits effectively provide a dis-incentive for clean energy options -- which must be overcome by even more taxes and credits. Back to languages, I see the costs in the limits of typesafe languages at a more personal level. I'd personally prefer to use typesafe languages for everything. Societal costs are a bit harder for me to rally around. Software is highly leveraged, with only a small percentage of the population writing software used by the rest of it. When it comes to security, I think our next beach-head is universally sandboxed operating systems. It's tragic to me that both major desktop systems today allow applications free reign of a shared filesystem space. I'd like every app sandboxed, more like Android. My old joke about this was "AIM should not be able to read my TurboTax files!" However, these are much easier technical problems than "grand unifying perfect GC", so I'm confident they will be solved as the market allows.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
