the fact i don't need to run the hideous iTunes Win port is yet another great feature>
iTunes for Windows sucks great big donkey nuts. It's slow, it's a pig, the click-to-focus-and-then-click is retarded, and it keeps forgetting the view settings for my iPod (while it has no problem remembering the other views; and they could at least choose some sensible defaults so that even when it forgets I don't have to delete four columns). I don't give a shit if that's how it works on the Mac, I want it to work like the rest of my Windows apps, and they're famous for being horribly inconsistent, but at least they get that right. If the Zune interface can nail those details then I'm sold.
Oh, you're still reading. I don't think my mail to you went through (from your website), PHP threw some sort of error.
Anyway, since the AC isn't here I'll explain a spinlock. Basically, you try to write a value into a word using an atomic compare and exchange (xchgl on x86). If the write fails, you loop (spin) for a very short time and the try again. You can also timeout if you the write keeps failing. In pseudo-code:
while (atomic write fails) {
sleep a little;
tries++;
if (tries > too many) {
give up;
}
}
I can certainly send you some code for doing this with C on x86/SPARC, but I'm lost as to how to do this (efficiently and correctly) in Java.
As for Dekkers, I remember doing that in OS but cannot find a decent reference to it other than the stuff that shows up on google.
It has a lengthy explanation of why it is broken in Java (because of possible reordering) and also a proposal for fixing the problem. Also see Bill's paper, in which he tells of discussions he had with Guy Steele (as in Gosling, Joy and Steele, The Java Language Specification).
An informed comment about GC on Slashdot! Hell just froze over...
old objects referencing new objects is bad for modern GC
If you assume that most new GCs are generational, since then you've got to track those old-gen to young-gen ptrs. But then it's not really "modern", c.f. Ungar 84. (It's also interesting to note that the GC in IBM's production VM is not generational.)
creating temporary objects is no problem
Absolutely. It's simply a pointer-bump to allocate, and it probably never gets copied between semi-spaces (and certainly never promoted).
why would you ever want to have a pool of preallocated objects which get recycled
Totally agree. Your pool (long-lived) is going to get promoted into the old-gen along with its transitive closure, and any time you allocate anything to put into the fields of those objects you're going to have old to young ptrs, i.e. more cardtable work plus more promotion plus more etc.
You'd think that Sun would have some clue about Java...
The people at SunLabs (who wrote the GC) do. Unfortunately, people elsewhere at Sun don't seem to pay them too much attention...
HotJava is a *web browser*, and is indeed EOL. But HotSpot is, like you say, alive and well.
BTW I interned with the JTech group at SunLabs East last year (Dave Detlefs & co.) and worked on new GC stuff in HotSpot. See my webpage (given in my user info) and drop me a line if you like -- be nice to hear from a fellow intern on/.
The problem is that it's still kind of nasty, because Java makes it very easy to have an inner loop with heap allocation occurring.
If those objects exist only within the scope of the (tight) loop then collection (but not allocation) is free, since they are allocated in the young generation eden space (in JVM 1.3+) and don't survive long enough to get copied into a survivor space.
you have to probably select the right size data chunk from a bin, find a free chunk (granted, if this isn't fragmented, it isn't *awful*)
Only in the old generation, and then only if it uses mark-sweep. In the case you give above, the objects are in eden, which means allocation is from a (per-thread) linear buffer, i.e. you just bump a pointer to allocate an object.
checking to see whether memory should be defragged and potentially defragging memory
Defragging is implicit in the young generation since you're doing copying collection between eden/semi-spaces. It's also implicit in old generation mark-compact collection, since you're compacting the space when you sweep for free objects. There is no defragging in old generations that use mark-sweep, but at least coalescing is free since you sweep the heap linearly (i.e. in address order, so finding adjacent free blocks is essentially free).
You're right, assuming that the VM uses native threads. I was thinking of having the threading implemented in the VM
IBM's
Jalapeno, now known as the Jikes Virtual Machine for Research, does its own thread scheduling instead of using native threads. The compiler generates yield points in method prologues and the back-edges of loops where the VM can preempt the thread. I suppose if you really wanted to you could have it generate a yield point for every instruction...
Herb wrote an article with Jim Hyslop on standards-conforming compilers:
Conversations: So Who's the Portable Coder?. In it they address the loop variable scoping issue which plagued many C++ compilers (and was discussed on/. some time ago).
Its a matter of keeping track of what memory is not referenced
Did you mean are referenced?
GC (and I don't mean reference counting) doesn't keep track of dead objects, but instead tracks live ones, since you trace the transitive closure of all accessible roots.
It is true, however, that in Mark&Sweep/Mark&Compact collectors you must visit the dead objects to reclaim them. Copying collectors do not share this problem.
Slashdot Mirror
the fact i don't need to run the hideous iTunes Win port is yet another great feature>
iTunes for Windows sucks great big donkey nuts. It's slow, it's a pig, the click-to-focus-and-then-click is retarded, and it keeps forgetting the view settings for my iPod (while it has no problem remembering the other views; and they could at least choose some sensible defaults so that even when it forgets I don't have to delete four columns). I don't give a shit if that's how it works on the Mac, I want it to work like the rest of my Windows apps, and they're famous for being horribly inconsistent, but at least they get that right. If the Zune interface can nail those details then I'm sold.
So can you teach me Fist of Fury? ;-)
Grennis: C# innovated!
Inigo Montoya: You keep using that word. I do not think it means what you think it means.
I don't even think any C++ compiler has achieved ISO C++ compliance yet
The EDG C++ front end is fully ISO/IEC 14882:1998 compliant, including export support. Look at their resellers for a list of compilers based on it.
You must have missed Cruel Intentions ;)
Anyway, since the AC isn't here I'll explain a spinlock. Basically, you try to write a value into a word using an atomic compare and exchange (xchgl on x86). If the write fails, you loop (spin) for a very short time and the try again. You can also timeout if you the write keeps failing. In pseudo-code:
while (atomic write fails) { sleep a little; tries++; if (tries > too many) { give up; } }
I can certainly send you some code for doing this with C on x86/SPARC, but I'm lost as to how to do this (efficiently and correctly) in Java.
As for Dekkers, I remember doing that in OS but cannot find a decent reference to it other than the stuff that shows up on google.
the double-checked-locking pattern is thread-safe
Bullshit.
The "Double-Checked Locking is Broken" Declaration.
It has a lengthy explanation of why it is broken in Java (because of possible reordering) and also a proposal for fixing the problem. Also see Bill's paper, in which he tells of discussions he had with Guy Steele (as in Gosling, Joy and Steele, The Java Language Specification).
An informed comment about GC on Slashdot! Hell just froze over...
old objects referencing new objects is bad for modern GC
If you assume that most new GCs are generational, since then you've got to track those old-gen to young-gen ptrs. But then it's not really "modern", c.f. Ungar 84. (It's also interesting to note that the GC in IBM's production VM is not generational.)
creating temporary objects is no problem
Absolutely. It's simply a pointer-bump to allocate, and it probably never gets copied between semi-spaces (and certainly never promoted).
why would you ever want to have a pool of preallocated objects which get recycled
Totally agree. Your pool (long-lived) is going to get promoted into the old-gen along with its transitive closure, and any time you allocate anything to put into the fields of those objects you're going to have old to young ptrs, i.e. more cardtable work plus more promotion plus more etc.
You'd think that Sun would have some clue about Java...
The people at SunLabs (who wrote the GC) do. Unfortunately, people elsewhere at Sun don't seem to pay them too much attention...
You're not Steve Blackburn are you? If you are, I thought you were at ANU/Amherst...
In any case, I spent a couple of summers working for the Persistant Java team at Glasgow. You can still find info on the implementation at:
PJama.
it does not scale across multiple processors. You get the same performance on one versus eight CPUs in the benchmarks I've seen
:)
And these would be which benchmarks, exactly?
SPECjbb 2002 Q1 and SPECjbb 2003 Q3-- look at the xSeries 360 and 370 results, where it scales quite nicely as you double the number of processors.
More likely it's just some sychronisation primitive(s) that they need to tune or remove
Holy shit, let's all rush out and tell David Bacon that his locks suck
HotJava is a *web browser*, and is indeed EOL. But HotSpot is, like you say, alive and well.
/.
BTW I interned with the JTech group at SunLabs East last year (Dave Detlefs & co.) and worked on new GC stuff in HotSpot. See my webpage (given in my user info) and drop me a line if you like -- be nice to hear from a fellow intern on
The problem is that it's still kind of nasty, because Java makes it very easy to have an inner loop with heap allocation occurring.
If those objects exist only within the scope of the (tight) loop then collection (but not allocation) is free, since they are allocated in the young generation eden space (in JVM 1.3+) and don't survive long enough to get copied into a survivor space.
you have to probably select the right size data chunk from a bin, find a free chunk (granted, if this isn't fragmented, it isn't *awful*)
Only in the old generation, and then only if it uses mark-sweep. In the case you give above, the objects are in eden, which means allocation is from a (per-thread) linear buffer, i.e. you just bump a pointer to allocate an object.
checking to see whether memory should be defragged and potentially defragging memory
Defragging is implicit in the young generation since you're doing copying collection between eden/semi-spaces. It's also implicit in old generation mark-compact collection, since you're compacting the space when you sweep for free objects. There is no defragging in old generations that use mark-sweep, but at least coalescing is free since you sweep the heap linearly (i.e. in address order, so finding adjacent free blocks is essentially free).
Fine, I'll list a few more for you:
:)
Katatonia
Nevermore
and, slightly more in keeping with the prog theme,
Spock's Beard
Transatlantic
Good taste, BTW, but I'm still not sure about that 60s South American psych-pop
According to the JVM Spec classfiles already have a version number:
/* 0xcafebabe */;
u2 minor_version;
u2 major_version; ...
}
ClassFile { u4 magic
The version is major_version.minor_version, and at JDK 1.0.2 it was 45.0.
Note that the VM executes first and only checks the version number when it actually loads a class.
You're right, assuming that the VM uses native threads. I was thinking of having the threading implemented in the VM
IBM's Jalapeno, now known as the Jikes Virtual Machine for Research, does its own thread scheduling instead of using native threads. The compiler generates yield points in method prologues and the back-edges of loops where the VM can preempt the thread. I suppose if you really wanted to you could have it generate a yield point for every instruction...
Sun license the picoJava core, which is the JVM on a chip, to a number of companies, including IBM and Fujitsu.
Herb wrote an article with Jim Hyslop on standards-conforming compilers: Conversations: So Who's the Portable Coder?. In it they address the loop variable scoping issue which plagued many C++ compilers (and was discussed on /. some time ago).
Go to your preferences and check the Anime box under Exclude Stories from the Homepage to exclude announcements about said subject.
Announced on the garbage collection list on the 28th of March, which shows you that at least if /. isn't paying attention some people are...
.NET) (articles,microsoft) (rejected)
* 2002-03-28 14:29:32 Microsoft release Shared Source CLI (for
Its a matter of keeping track of what memory is not referenced
Did you mean are referenced? GC (and I don't mean reference counting) doesn't keep track of dead objects, but instead tracks live ones, since you trace the transitive closure of all accessible roots.
It is true, however, that in Mark&Sweep/Mark&Compact collectors you must visit the dead objects to reclaim them. Copying collectors do not share this problem.
Have a look at an article on IBM's concurrent collector
Tony got Richard Jones to sign his copy of the book the last time he was up here visiting. Richard signed it:
:-)
"A Good Collection of Garbage"