gc


On Thu, Jun 23, 2011 at 07:37, Johan  Lundberg <joe...@gmail.com> wrote:
I have a novel idea concerning all manner of "helpful" memory
management, like Garbage collection (GC) and Reference counting: Drop
it, bury it, forget it.
>
Manual memory management is really not difficult. All you need to know
can be summarized on one sheet of paper. Make a few mistakes and in a
couple of days you will have figured it out. Your programs will be
fast and predictable.
>
Automatic GC starts up randomly, which is a huge problem in time
critical applications, such as in the financial markets. Someone at
Oracle told me that 98 percent of all JVM optimization investments
concerns the garbage collector. This, and the fact that automatic GC
makes programmers lazy and unaware, is a very high price for the
miniscule convenience of not having to release memory. Reference
counting is slightly better in that it is predictable but it is very
confusing to many programmers. Unless you have a very powerful
development and simulation environment it is therefore more prone to
memory leaks than manual memory management.
The same arguments can be made for programming using just
NAND gates, which can be summarized on just a post-it note.

It turns out that, compared to writing programs using NAND gates,
when I write programs in Go, I can write the program in less time,
the program is more likely to be correct, and the program is easier
to debug and fix if not.  It is true that the program is slower and
less predictable than if I'd written it using just NAND gates, and
not having to think about NAND gates probably does make me
lazy and unaware at some level.  For the programs I am writing,
the advantages of using Go outweigh the disadvantages of not
using NAND gates.

Of course, programmers and programming environments differ,
so if you find that NAND gates are a better fit for your work,
no one here is going to force you to use Go.

Russ

>>28
C and C++ are not suitable for it either. You want a language whose behaviour is always well defined, and has manual memory management.
You wouldn't use C/C++ either, just a subset of it, so why don't you just use something else? (finding such language is left as an exercise for the reader)

>>40
It's not, I agree, but not using a GC should be the exception, not the rule. I'm tired of manual memory management bugs and memory leaks, and people thinking that GCs are not needed/slow.

That said, there exist deterministic, real-time GCs that can be used in soft real-time systems, but, yes, for hard real-time systems, it's probably better to statically allocate all the memory.

       ________)
      (, /      
        /___,   
     ) /        
    (_/  A G G O T S.

>>41
GC is a good general solution to many problems. Programmers should use other memory management techniques when necessary.

>>41
If GC is so good, how come you don't use an OS that has a built in GC and uses GC in the kernel? Huh?

>>44
Because of compatibility with old, deprecated systems.

>>45
Like what? Lisp machines?

the stack/heap distinction is an abstraction that is both leaky and useless. Discuss.

>>47
Do you realize that your shameless bump might potentially ruin this relatively good thread?

>>48
it was my plan all along.

>>49
You are a truly awful person!  A veritable evil genius, I say!

>>46
LispMs had hardware GCs. IHBT

>>3
This applies to so many things.

The problem I have with proponents of x is that they take a very militant stance against x: as if x, y, and programmers who z must be eradicated from the face of the Earth, as if they were some kind of disease.

NAND:Niggers Against Niggers, tru Dat

>>47
Agree! There's no reason for separate stack memory, especially with modern generational GCs with amortized O(1) allocation speed. If you allocate your stack frames with your GC, you can get a bunch of other shit for free, like tail-call elimination (when compiled to continuation-passing style), closures, first-class continuations, etc.

>>54
TCO, continuations, closures, etc, have nothing to do with heap allocated slow as fuck GC managed activation records.
IHBT.

If you write in C, why not just use alloca() instead of malloc() for everything? Is that not a very simple, predictable 'GC'?

>>56
Your stack frame risks being destroyed. You seem to miss the point of heap allocation.

>>4
How hard is it to put 80% of your stuff on the stack?

>>56
http://compilers.iecc.com/comparch/article/91-12-079

Still, i would not overuse malloc, like some people do in cases when you can in fact just put an array on the stack / data area and be happy.

Im looking for a print function, it cant be printufu (thats japanese for printf) or any stdio function. It has to be of 2 or more parameteru (thats japanese for 2 parameters) and has be be chibi (small) sized. And has to be really kawaii (cute). Also It has to be about 10-20 bux. And you have to post documentation of it first (i want to make shure it's kawaii [cute]). And it would be nice if it came with matching input reading (WITH error handling). OH! and it CANNOT have any complicated syntax, or be made out of C. It has to be made of C++, or something like that. Also it would be nice if it was made in japan. and not in china or corea (korea) or whatever. I have found a function similar to the one im describing in sourceforge, but it was 1 parameteru, and i dont want my formatou (formatting) to touch my other things (it can get mixed up and i would not like that, plus 2 paraneters looks more kawaii)

>>60
printufu (thats japanese for printf)
Japanese for printf is purintoefu, not printufu.

>>61
I love it when people argue with kopipe.

KONNICHIWA SEKAI-KUN!!

>>61
purinutofu

>>64
purintofu

ONE WORD: THE FORCED COLLECTION OF GARBAGE, THREAD OVER

>>5
What do you mean by cycling references?

>>67

(let ((x (list 1))
      (y (list 1)))
 (set-cdr! x x)
 (set-car! y y)
 (set-cdr! y y)
 (values x y))
; => #0=(1 . #0#), #1=(#1# . #1#)
In refcounting, `x' refers to itself, its reference count will always be at least 1. Same for `y'. Congratulations, you've got a memory leak!

x=#0=(SOME_OBJECT . #0#);

/* Recursively free a list. */
void free_list(List *list) {
  free(CAR(list));
  free_list(CDR(list));
  free(CDR(list));
}

free_list(x);
{ free(CAR(x); free_list(CDR(x)); free(CDR(x)); }
{ /* SOME_OBJECT free'd */
  free_list(CDR(x)); /* The cdr of `x' is `x' */
  free(CDR(x)); }
{ /* SOME_OBJECT free'd */
  { free(CAR(x)); /* Double free */
  /* Segfault */ } }
If you don't free the content, it will just loop forever. Also, y=#1=(#1# . #1#); free_list(y); will first free itself, then dereference a free'd pointer.

http://www.loper-os.org/?p=37
I see this as a convincing argument for “silicon big government.” Move garbage collection, type checking, persistence of storage, and anything else which is unambiguously necessary in a modern computing system into hardware – the way graphics processing has been moved. Forget any hypothetical efficiency boost: I favor such a change for no other reason than the fact that cementing such basic mechanisms in silicon would force people to get it right. On the first try – the way real engineers are expected to. Yes, get it right – or pay dearly.

Automated Garbage Collection
/prog/

Undoable. There is so much garbage on /prog/

>>69
great, a lithpfag OS. I hope it dies along with its idiotic creator

>>70
You'd get garbage collected with >>71.

>>72
fuck you lithfpaggot