CoC - https://rubinius.com/code-of-conduct/ | Install - https://rubinius.com/install/
I'll add some niceties probably tomorrow
since I have the MemoryVisitor now, I need to implement
become as well, which will make programming proxies really nice :grinning:
another thing we can do with MemoryVisitor is search a subgraph of the object graph, say from an explicit set of 1+ "roots" instead of the graph roots
I should expose some nice methods for that in
Rubinius::Memory
will play with them soon
thinking about the JIT, here are some things that are important:
- I want to respect "do a little, get a little; do a lot, get a lot";
- by using functions as the interface between nanopasses, we can leverage
f: A -> B, g: B -> Cfor composition of passes; - we need an explicit mechanism for describing dependencies independent of the function composition;
- then 2 and 3 give us the ability to parallelize compilation where dependencies for pass B(i) are met by an B(i-n), n >= 1
I wish it was easy to do subscript
I need to make one more change to set the thread_id of the Thread and not Fiber into the object header
since all Fibers attached to a Thread should be able to update an object created by anything on that Thread
- a logging facility that will tell me when there is cross-thread access (or just mutation?)
- the ability for the aforementioned logging facility to
raiseon cross-thread access (mutation?)
- better GC
question: are the isolated heaps implemented yet or just this logging mechanism? if implemented, are they exposed to Ruby-land so I can say
Thread.new(heap: :isolated) or Thread.new(heap: :shared) or something?
back to your question… i have a long wish-list but i think i need to subordinate my desires now for something that this community needs which is a taste of the JIT
we want to entice some folks back into the fold but pretty much everyone runs for the hills when they see the current performance levels; if you could spike out a few nanopasses and get some inlining or peephole optimization or onstack replacement or whatever working to boost regular perf then that would be great
there are a lot of improvements to the GC, more to do
isolated heaps are not yet in, I'll add back thread-local allocation first, and then the ability to create isolated heaps
the isolated heaps need something like "main()", which will be a function, and they won't be able to use Ruby classes unless I come up with a reasonable method to inject those references
the "closed" heaps, which all pointers out of the heap, but not into the heap, can use Ruby classes
I hear you on the JIT, I'm on the same page, so I'll get some basic functions in, and then spike some JIT functionality
a call to
localtime_r is calling tzsetwall_basic and that's trying to aquire a lock that is not held in this process
the only thing I can think of is that the lock is held in the parent before
fork()
which means that we're racing the logger when forking, but I can't figure out how
I may be able to implement thread-local allocator, but really want to get
Object#become in place
describe "Object#become" do
it "replaces the receiver with the argument bidirectionally" do
a, b = "me", "you"
a.should eql("me")
b.should eql("you")
a.become b
a.should eql("you")
b.should eql("me")
end
end
:laughing:
Object#become may seem whimsical, but it's not because the same mechanism must work to implement evacuation / compaction in the heap
right now, it's not working for object instance variables, for example
this can also be a useful mechanism for injecting a reference into an "isolated" heap
never happened :)
he’s a theorist (which we need) but i wouldn’t rely on him for much beyond that