freenode/#sicl - IRC Chatlog
Search
4:55:41
no-defun-allowed
Most likely more programming, since I can't think of anything better to do.
4:59:01
no-defun-allowed
The first things that come to mind are continuing making object replication in Netfarm more efficient, and basically rewriting my concurrent hash table with my recent commentary (which I had collected into a document).
5:47:55
no-defun-allowed
I found a conversation between David Moon, Cliff Click and Daniel Weinreb, which is a fine distraction for today: <https://web.archive.org/web/20100302033837/http://blogs.azulsystems.com/cliff/2008/11/a-brief-conversation-with-david-moon.html>
5:50:53
no-defun-allowed
Parts of it are comparing Lisp machines and Click/Azul's "Java machines", some hardware assists for Java and garbage collection, and handling approximately too many cores.
5:53:54
no-defun-allowed
Click seems very pessimistic about garbage collection and swapping, saying that "the JVM might as well have crashed"; would the CLOSOS GC have to be aware of where pages reside on disk?
5:55:21
beach
I don't think so. The design is such that the paging is done at the very lowest level.
5:56:07
beach
The GC is like any other application code in that respect. It can assume that all pages are in main memory.
5:56:23
beach
But, I haven't thought much about the performance implications of the GC walking all over memory.
5:57:28
beach
If we use the GC design that SICL has, there should not be much such "walking" since the global GC is not copying.
5:59:00
no-defun-allowed
Yeah, as in that optimisations which, say, defer marking paged-out objects and attempt to keep disk reads sequential, might improve performance. (Though I made up those two ideas on the spot, they could well be nonsense.)
6:00:08
beach
The mark bits are separate from the objects, so there should be no paging activity for live objects at all.
6:01:04
beach
I'll read that article during the day. This is Monday, and Monday mornings are chaotic around here.
6:01:40
beach
This discussion reminds me that someone needs to figure out what GC support we need in RISC-V.
6:01:45
no-defun-allowed
I recall a write up where the author modified the Linux kernel to inform some implementation about which pages were paged out, and the implementation would use that information to avoid scanning swapped out pages.
6:02:07
no-defun-allowed
But looking up "swapping aware garbage collection" brings up information on the similarly named process for SSDs.
6:06:30
beach
Anyway, I still remember a phrase by the guy who gave Multics courses for the company I worked for at the time: "Virtual memory is a way to make a lot of memory look like a lot of memory."
6:09:23
no-defun-allowed
I recall having significant slowdowns with...a large interactive Java application and swapping, and there is a syscall...somewhere that checks if a page is paged in or not now, so I wonder where that research went anyway.
6:21:33
no-defun-allowed
Here we are, "Garbage Collection Without Paging" <https://people.cs.umass.edu/~emery/pubs/f034-hertz.pdf>. After re-reading it, it's quite different from what I had in mind. Linux also provides a /proc/<pid>/pagemap file which can be used to find the status of pages, but it's not clear how that works.
6:24:29
no-defun-allowed
Oh, it is described in <https://www.kernel.org/doc/Documentation/vm/pagemap.txt>
13:39:35
beach
Once we start generating native code, we are going to need a disassembler. That would be a thing that I could subcontract.
13:40:09
beach
Also, it would be good if it didn't just generate x86 assembly instructions, but also some intelligent comments.
13:41:15
beach
Such comments would require additional information, but we already have some of those. For example, the call site information relates an unconditional jump to a named callee.
13:42:06
beach
It would seem that some debugging information could also be used to generate such comments.