 Okay Right, so this paper is about garbage collection, so not the usual kind but in the programming language Any case I have to say that this slugs came from The authors of the paper, so I sent them an email saying that if they could give me permission to use it for this meetup And they came back really quickly, so I was very pleased and they gave me permission to use this So this is done by the authors not by me So if you find this online, it's because it is it is by the authors They can communicate Sorry Anyway, they gave a nice name to this the paper I think they have much better scenery than the view the acronym is ORCA Orca, which is the The memo is here So it stands for ownership and reference counting based Oh, it's not reference counting rc is reference Collection to the c's for collection. Okay. Didn't know that. Anyway Uh in the actor world So, I mean if you follow the work to the authors, they're actually involved in this new program language called pony I think it's sort of the phd thesis of the first author In case you don't know, I mean when you read papers, right, usually the first author is the phd student The last author is the professor So in case you're wondering flash the email to professor. So just to Think she gave this as a workshop in europe Anyway, uh, let's skip this Anyway, I think this is the motivation of why study garbage collection, right? So, uh, there's duck lee If you don't recognize, uh, duck lee is somewhat famous for the duck lee melloc so even in non-gabbage character languages Like your basic primitives like melloc is difficult to do these Fairly efficiently for high performance systems, especially for multi-core multi-threaded systems Imagine you have two threads asking for memory at the same time, right? How do you allocate and so on I think that here we're talking about the jvm. He does quite a bit of work on the concurrency I think he's on a concurrency Team for the jvm So for most languages, you're the problem that If your garbage collection is a concurrent, which is what you want Otherwise, you have to stop the world stop everything and do garbage collection. So if you want concurrent garbage collection Then they run together with the The application and the application could be making changes to the the memory Right and that's problematic for your garbage collector because it's trying to ascertain a particular state of the objects in memory to collect the garbage So you need to resort to things like synchronization and other tricks to Or read barriers write barriers to Get things to work but they reduce the performance because all these barriers Includes additional instructions when you try to de-reference or look up an object okay, so I think this is interesting because We are moving to a very special System which is actor base So this is from Carl Dewitt Thing in the 70s the idea of actors is Uh, they have at least in in pony. Anyway, they have behaviors So if you call a behavior, it is it is in some sense asynchronous. You don't get back any result But so it's like the idea is like you send that actor a message I mean in here they call it calling its behavior and This actually this algorithm relies on two essential properties of the system So the first is the behaviors of actors are atomic So they don't happen in the middle of garbage collection So at least to the garbage collector the actor behavior is like a single step operation So in a sense that solves kind of the concurrent problem, right? Because there's no there's never any concurrent activity with the actor and the garbage collector So that's kind of nice But it's still useful because this is kind of like the airline system where each actor has his own heap So and it garbage collects its own heat which is relatively small Compared to I mean the typical shed memory system like the jvm which is one gigantic heap shed by the entire Application so each in this case is sort of individual heaps And the second property is causal messaging So when the actors send messages to each other they exhibit this They follow this causality. So if one message was the cause of the other it would It would arrive before the effect. So the cause is before the effect the general notion of putting out there's more details in the Departments lights Anyway, okay, so the two key problems Here is okay, for example your actor might send an object to a different actor And then it itself does not hold any more references to that object So how would it, you know, be able to garbage collect right? And of course references to the object. Okay, so I think there's something which is not really mentioned here but it's in the paper is that the The trick here will be to have every actor When it constructs objects it constructs it in its own heap as I said, there's their individuals heap, right? And the actor is responsible for also cleaning its own heap So which makes sense right? So an actor can only garbage collect its own heap. You can't garbage collect other actors heap It's all separate These are sort of mini heaps or not the the gigantic heaps we're used to So but because the trouble is the actor may send objects around and how does it keep track of This object right when it goes to other actors and so on And there's the idea of foreign references Which can be more details And then the foreign references might change because of objects being sent around and then you can Just I'm just here you can send messages itself to reconcile the view of the The objects so I think there's a very concrete example That we will see very soon Okay, this is a very complicated slide. I think it's supposed to have some animation, but the animation was in keynote So not very helpful to my uh, non macintosh system But anyway, uh, so just ignore the the words for now and look at the left hand side um, okay, so Represent actors with this a so a one and a two are two actors In the system think of actors like lightweight threads kind of So the boxes represents the heap of the actors and the Blue entities are the objects. So these are just so this is actually an object oriented language you can you can construct regular structs and classes and stuff so So they call them passive Entities but actors are considered active entities so here you have four objects oh one two three four And the arrows, uh, you think of them as references, right? So actor one has references to object one and three and so on Okay, so that's the top part the middle part is the message queue So every actor has a message. That's how you actually or a mailbox actually That's how you actually send it messages it goes into this queue And the actor just you know pops off pops off, uh, I guess from the left messages and you know Runs his behavior on the the arguments That's the queues um The working set is kind of like the objects this actor knows about or he has seen before and So correspondingly for every object he knows about there is a count Which is the number or which is the total weight of the references to that object So this is going to be as the title suggests it's going to be a reference counting system Right, so basically and it's sort of a unit direction also. We're only counting references from actors to objects So it's from the active entities the actors to the sort of passive entities the objects we're counting how many Not not really how many but you think of how many references are there from From the actors to the object. So this is how many references from actor a1 to all it is known Entity so we actually also include the actors themselves this system can actually also garbage collect actors But that's not the focus of the paper actually there's a different paper talks about how to garbage collect the actors So in this paper focus mainly on the garbage collection of the objects so Total of objects that they have It's it's a weighted count actually just to be precise. So it's not really the number of count It's so there's some weight factor inside. So yeah, don't think of it as the number think of it as a weighted number Yeah, so there's some numbers, okay Oh, okay, and then I think there's some nice things which the gray cells represent owned objects So again, you can see from here. So actor one owns object one and three actor two owns object two and four Own means belongs to the heat. Yeah. So why doesn't they No, because it's actually like no people on the right hand side, but There's no entry for a why there's no entry here. Is it? Yeah No space. No, no, no because like it explicitly mentions it, right? Yep. Sorry. Where does it say that? No, in the working A204. Oh, no, no a2 Because a2 doesn't have all three No, no, is that about oh four, right? I think it's just no space actually. Yeah. No, it definitely has a count. I'm sure Oh, no because your booking set is 010204 so your count table should be 010204 Not necessarily. I mean look at the definition of wrap count table for some addresses from the working set and it explicitly mentions that there's no entry for it Looks like there's some insight Nope, I can't kind of explain why Sorry about that Okay, it says there's no entry. I mean no, they don't show the entries. That's why I would think there's just no space for it actually Yeah, but I may be wrong I'm just guessing Okay, in any case So the approach here will be how I'm going to do this is How I'm going to show that this this algorithm actually works Is we're going to define a number of invariants so as in typically in any kind of proof and algorithm we define number of invariants and We're sort of sure that the algorithm maintains this invariance as it sends objects back and forth between actors Okay, so to define the conditions of the invariance we need to define a few terms Okay, so the first term is this local reference count So that's quite simple. That's just the reference count of the Let's look at this one lrc of o2. It's just the The value in the count table of the owner of the object So o2's owner is a2 so the local reference count for o2 is 4 and same for well, but default the actor is his own owner. So The reference count of a1 is 12 So that's just that's quite simple Okay, the foreign reference count is sort of the Inverse so it is the all the other counts, right? So all the non-owners Of the actor. So what's the example here? Let's look at the it's always the actor. Okay, never mind. So The foreign reference of a2 is there's only one other actor in the system So it's going to be just a1 But if there were more actors, then you would add up all the The a2 values in all the actors except for a2 So if there was a3 then you add up the value 5 plus the a3's value, right? Yeah, so that's just that Okay And then there's one called the increment decrement count So these are basically garbage collection specific messages that we are sending to reconcile our view of the The heat the global heat so to speak because the heat is partitioned into many actors So we need we have to send messages between actors to reconcile the view So this increment decrement count is the So there's a number here, right? So this means increment by 1 But it could be a bigger number increment by 5 Then there could be decrement count d ec is not shown here So dc messages. So just add up all the And these are these are actually called weighted references. That's why the number is not only can be 1 can be larger numbers because it's weighted So just add up all the messages in in your queue And these are okay. So the thing is these are only sent to the owner Right because well the owner is the one that has to take care of this this object, right? So whenever some other actor deals with this object Oh one he's got to send a message to the owner say, okay Here's what happened to this oh one your your guide, right? Because you know, it's being moved around whatever So so these are only ever in the owner's queue What does weighted reference mean? For the reference count I don't know about much about right Weighted reference just mean Each reference is an integer number It can be like Doesn't have to be like just like the actual number of references per se. It's it's just it has a It can it can vary right? It can be like 105 Yeah Hard to explain it's like maybe like Does it mean like higher number in the stronger reference? Not really Not really because not normally when reference counting right Yeah, I think in this case This is like more of an optimization. I think so I think we can just Pictend we ignore the weighted case actually So I think what happens in here is there's this occasion We have to send the same object many times and then instead of sending these messages Over and over again is get get kind of inefficient so we can just send like one message Hey, I'm going to potentially in the future send this like hundred times. So some other guy So I'll tell you increment 100 first Then I can do a lot of stuff with it. I don't have to tell you anymore because I told you one shot Okay, so that that's the sense of it. I guess So we can in the naive case. You can just imagine we always send increment one Right, but I think there's some optimizations where we can batch it together and send increment 100 Then I do stuff with it. I don't have to tell you I told you in a time Right. Yeah, so instead of every cent I got I got a so I got to update you. I guess I just tell you, you know Well, I yeah I'm gonna have five references. Yeah. Yeah. Yeah, then I'll just do that and then you forget about that for a while Okay, so yeah, so that that's the idea Increment reference count. Okay. Yeah, this part is a bit dry. But never mind. Okay And then one last part is the application message count. So we always write this as a pp So these are the application specific messages, which is like in your program. You say this actor Sends a message to that actor. This is in yours special in your own program, right? This is part of the garbage collection Protocol so you don't you don't have to worry about this this happens automatically So these are the ones you program in yourself, right? So these are called application messages and they may contain References to objects, of course. Otherwise, why would you send them? So They can add up all these as um, so notes actually that The definition here Let's say number which contains Alpha uh, alpha where alpha is the object addresses reachable from alpha and the owners of alpha but Which actually just involves you need to trace the you need to trace this object if it's more complex if this object has The bottom oh one actually has links to oh two So this this this this message at oh one It also affects oh two because anyone with reference to oh one actually can Refer to oh two because of this Link here, right? So you're actually worried about all the reachable objects from the message from the address in the message So we consider all the reachable addresses as also sort of contained in this message Right Okay All right now Okay, I think we can skip this not terribly important Okay, and the key invariant actually is that is w f zero. So the key invariant Say is that actually tells us how we define this Local reference count Okay, something like this the local reference count of an object is In fact the same as ignoring messages Ignoring the idc and a and c is actually the same as the sum of the foreign reference counts And then whatever you send messages, which is the amc part you also send this increment decrement messages to to update the the owner because you're transferring your Ownership in some sense all your references And the rest are just kind of Intuitive I guess so it's like reference counts are always non-negative because this makes sense to talk about negative references And this is reachable stuff like I think which is which is quite obvious So so for example w f three says if a message an object is reachable from some message Then it cannot have a count of zero otherwise when you have a count of zero will be collected Right, so just for just for correctness when you have this object in some message It has to have a positive count so that it will be alive when it reaches And really the whole point of all this Different invariants and the first one is really the one that's most important the rest is sort of the intuitive things It's really to have this consequence at the end And that is basically saying if an object is not reachable from the The owner and the count And this count is zero which also implies that nobody else has a reference to the object with address alpha and there are no messages with Alpha in the content Then this is implies this is globally unreachable, right? So that means we can be it can be collected as garbage And the crucial point is that this condition this first two conditions actually this is a conjunction of two conditions is checkable Uh purely by looking at your count the owner's count table Yeah, that's right. If actually what happens is I will tell you when they do things so you kind of update so but eventually just check your own tables and then when you see like But when there's a tracing step when you trace the object you cannot reach it and then it's counted zero Which also means nobody else Because you can't reach it doesn't mean somebody else can't right, but then this additional condition Means somebody else can't so I can't reach it And everybody else can't reach it, right? It's actually that's what it says in english Which obviously means nobody can reach it because these are these are the whole All the entities in the system, right? So you can collect it is basically garbage So so that's key the key is that you don't have to ask anybody anything to do garbage collection So every actor can do garbage collection independently of every other actor And that's why it's um Efficient also right because you don't have to check anything you have to ask anything right you just Check your own tables and then okay. This is garbage. I can get rid of it If it's not enough that the local rep count is out for zero Hmm The name local rep count is kind of a misleading thing. It's actually totally up all the foreign counts I actually never count my own references. I just do this check actually Reachable this is which it bull is for myself. This is actually asking about everybody else Although it's called the local rep count, but it's kind it's kind of a I see Yes, exactly exactly it's kind of a funny name, right? So yeah, yeah, so this is actually the sum of all the foreign counts Yeah, it's not my count. I actually don't care about the count. Let's care about which ability actually So I can't reach it and nobody else can see this Nobody's and this includes also of course not just actors Actually, this includes messages if you if you think about it. So this includes messages as well as other actors Because it could be in transit, right? So nobody can see it, but it's somewhere in between like in the messages, right? so it's a basically locally you do a It's a trace. Yeah mark Just do marking And then you also but but for me more preference This is kind of like the global view in some sense. Yeah, this is the global view. The global view is Locally Yeah, yeah, so together the two yeah, exactly We can prove that is unreachable You can't you can't collect it No, this is and and and both must be both must be both must be satisfied Oh if you can reach it and that is zero you cannot collect it otherwise what you're using is gone, right? I'm using this. I'm sorry. It's gone now. I can't do it, right? Basically if the local reference is zero then this degenerates to the one single thread Yeah, basically that means this is uh, it's my personal object. Nobody else sees this. So, yeah Okay, so that's No, they're not they're not that's that's the thing, right? So they are They're like green they're like green threads. So actually what happens is if you look at the action presentation So there'll be like a scheduler and then they'll create actual threads Which is equal number of cores and you schedule the actors to run on each of your cores We can we can have millions of actors. They're pretty lightweight And and the cool thing is they have separate heaps. It's kind of like the erlang model Um, so where is okay. Let's see. Okay. Uh, okay. I thought about the how you do the this is the marking basically This is like unfortunately the animation is not here. So Uh, so what you do is you do marking like basically and then and then you trace from your fields. Okay, so the thing Think about this also is that the garbage collection happens Outside of your behavior. So your behavior has said it's logically one atomic step to the garbage collector So what happens is after you run your behavior, it may choose to run the collector So which is why there's no problem of uh Concurrency right because we never run it together with the behaviors, right? So we always run it after a behavior. I mean you can check whether there's a lot of garbage If not then we can do another behavior. It does okay. We're kind of full. Let's do a gc And then you can do this because you have split it up into this actor model. So each Step is small enough that you can do this and that. Exactly. The popular term now is microservices. You can think of actors as your micro component services, whatever, right? Yeah Okay, so there's no need to worry about Tracing your stack and there's no stack because this is when the actor is uh Between between jobs so to speak, right? So there's no there's no active stack. So you just trace from the fields Actually, so the actor is like a class. He has some fields and all that So you can just start marking these things as reachable And so on and then all the you so this is I think a 2 doing gc, right? Yeah, so a 2 doing gc. It has no Well, I think I need to be o3 here. So o3 actually I think it's gone right because o3 is not reachable It is post animation. Yeah, I think yeah post animation. I think all the all the animation finished So basically when when o3 o3 is gone. So whatever count you have in your table, you just uh set it to zero What are you gonna tell the owner? Okay? I didn't see this guy anymore It's it's gone. So it's gonna tell the gun, right? Because a once yeah, yeah Oh a 2 a 2 from a 2. Yeah. Yeah. No unreachable, right? Unreachable. Yeah. Yeah, exactly I can't see it a 2 can't see it. This is all about a 2 So whenever I say me and I'm saying a 2 so a 2 can't see the o3 anymore So I set it to zero that previously was one assuming So I tell uh, I tell the owner. Okay. So uh, what I saw previously was should be gone So whenever I was one I should subtract Of course when he sees this message it would as you would expect update its number. So you would It would actually update its number to zero And I also don't see it right now later. You'll see okay. Let's see this So a 1 is doing garbage collection up So a 1 blah blah blah and then and so on and it process all the messages Sorry, I assume it process all the messages, right? So Uh, and o3s are reachable because you know, there's no links to it And it's zero because you process the decrement message And now we can collect, uh, o3 We turn it back to The memory allocator Basically call free on it So the queue need to be empty when the garbage collection is over? Um, no no not necessarily Uh In this case, yes, but in general no doesn't have to be yeah Yeah, there's also what what other condition which I think it's not did I Oh, it's not in here Yeah, so that that comes to this fifth thing which I didn't talk about the pending changes count Uh This is required actually so that one of the conditions says that the the prefix sum of the queue cannot be zero When the message still exists, which makes sense. So even though it's zero now, it could be non-zero later. So Any case That's kind of a detail Yeah, but there doesn't have to be anything so you can you can process some messages because each of this is like doing a behavior, right? Each of this uh message You can process some and then you can do gc Up to the schedule to the site when you want to do gc Uh So I will not talk about this Okay, so basically what what when do you need to? uh Bother of the gc stuff So when you send and receive messages because you get new references or you get rid of the ones you have Right or when you receive the special messages, you're going to update your count and Yeah, let's look at an example, right? So what happened if you if you run a statement like this so Uh, yeah, you a1 And you set your f to f is this link to now So this is running the behavior running your um Your code, right? So actually when you do this, um You don't have to do anything Because we don't care we only check at the end, right? We don't do anything in between behavior So at the end of the behavior when we let's say you have not much memory left We may do a this whole mark and trace business and we'll eventually discover that o3 is unreachable Right, and then we will say okay, and then it is zero. It's not zero So we can't kill it, but if it's zero then we'll kill it So this is fine. So this is good because you don't have to worry about it doesn't slow down your normal behaviors Not unlike your like say read barriers or write barriers Uh, oh, and here's where things get complex. So if you need to send a message so If a1 sends a message to a2 here we go with the object o1 Okay a1 and And a1 is the owner of o1 Yeah, great. It's great color box which is the owner So how so and this is the key um, the key invariant actually So how do you preserve this? So what happens is that uh, obviously you have the You have that one amc o1 becomes plus one because we just sent a new message so the number of references in that message in in all the messages combined is Equivalent by one What can a1 do? To balance the equation So basically you can just increment This number The lrc Which makes sense because the lrc is the global view, right? So now I introduce a new message I have to update myself To say that now in the global view there is this new message with o1 inside So I have to increment This is the lrc Because rc of a101 is Essentially the lrc because a1 is the owner of o1 Right and Okay, these other ones are because All these other things are also in the message because This is the owner of o1 This is reachable from o1 This is the owner of the thing reachable from o1 So they're technically Part of the message Indirectly in some sense So you also got to increment Oh no, yeah you got to increment This is some fact This is to do with o2, forget about this Anyway, this is this part Oh, o2 is because sorry So o2 is because Yeah, so I have to explain this O2 is not my Object This is a1, right? Remember? So this is the owner This is the non-owner The non-owner case is kind of the inverse So you got to This is actually the so called the foreign reference count Because this is the count of a1 In respect to o2 So you got to subtract From there Right because you incremented there So you got to subtract from here to Sort of balance the equation Right Because it is the owner of o2 And it's not myself So it's also not subtract I think there's just one more Causality Actually causality is important I guess you can see why Because otherwise these messages get out of order So it's important that these increment Decrement messages are received in the correct order Otherwise You receive too many decrement messages at the same time You would think that it's actually gone So we should sort of why the causality thing Is important so they have to come in in the right sequence Otherwise your view of the world Is a bit incorrect So Okay The other key thing that is enabled by this Is that of course you could say that Well I send an object and some other I do all this tracing And all that business but wouldn't You might argue that when I do all this tracing business What if o2 gets Changed by a2 Because when I do tracing from A1 I will actually trace until o2 But I don't own o2 So a2 might be running its behaviour And doing stuff with o2 Does that make sense Which is bad right? Because I'm trying to trace how things are going But a2 is modifying o2 Adding links and all that stuff So that's Good right? So it turns out with the type system Of The language The compiler can actually prove that that's not possible So the fact that O2 Is visible from a1 Means actually nobody else Is actually modifying it This is something from the type system Actually So when you compile the program it will not allow you to It will not allow a2 To actually be modifying o2 When it's visible from a1 Because that would be concurrent mutable state Which is not allowed by the programming language itself You know where it's immutable for example It's one of the possibilities So o2 could be an immutable kind of thing So a2 could not possibly modify this When it's being traced from a1 It's not o2 that is immutable The reference in some sense The reference exactly Of course a1 Could later modify it So a1 could be able to modify it But from a2's point of view It's true this reference Is not able to modify o2 So actually if you look at a different paper Talk about this, it introduced something like I'm not sure whether it's a bit of a cognitive overload There are six different types of references To track the Who can modify what But the good thing is This allows us to say that it's not possible You can't get any concurrent problems here Okay I think that's basically it So all these basically are No actually So that's The other interesting thing about Pony Maybe the different paper No time to talk about it here actually So you can Look at some numbers actually Look at some graphs So this is comparing Pony o1.5 I think now we're at o2.1 With a bunch of other things So the most obvious one is comparing with Erlang Which is the green line Kev is the C++ actor framework Especially the C++ I think Charm is also a C++ based Actor framework And this is Creating many many actors And also doing GC On them at the same time Pony isn't that fantastic Pony is the black one I think right Especially when you go to many many cores At like three actors This one? Oh this is Two cores This is about million plus actors Sorry yeah No idea Contention Synchronization Yes you already have overhead synchronization You don't have with one Sure But I guess if like three or four you get more work done And the overhead is actually relatively less So this is for Charm But this isn't Exactly selling Pony right Because you'd expect that Not fantastic All the other ones would not It's more like comparable Because it's the whole point That can increase the cores And you don't suffocate In synchronization I guess this means It's kind of flat right so it doesn't Get affected by this Yeah So you should always get two cores You might have big machines So let's look at something better This is the This is to do with the messages So it means you're sending messages To all the mailboxes So where is this the first I need to talk about where this is from So if you know actor frameworks Erlang is the most famous And Erlang has a little problem with this Because Erlang essentially says you shed nothing at all When you send messages you just make a copy of it So there's no sharing so that's perfectly fine But making a copy takes some time And notice in Pony when I share a message I literally just share The reference to the object Because of the guarantees that If I send to you I can't modify At the same time and so on because of the type system Which I'm not talking about But because of that I can send you the whole thing Because nobody else can touch it So it's actually More performant when you send lots of messages It's essentially what's called zero copy messaging So I don't make copies of the messages I just send you the whole reference But I have to do this tracing business to figure out Who is reachable from the message That's the caveat actually So this does pretty well on Lots of messages so more real I think this is a factoring example So a bunch of messaging and computation Combined And it does quite okay In fact I think Pony if you look at the code And this is a GitHub and it's still pretty young It's mostly written in C actually I think if I look at the master's thesis This started out mostly as a C library And then they wrote a compiler On top of it to call the runtime Which is basically in C Which does all this mail boxing And sending messages business So Pony can think of it as like a C A C thing It's a C++ but not a C It's C but the way the compiler works It's kind of The runtime is written in C And when it's compiled down to LLVM it's backed by LLVM And it calls into the C runtime But the compiler when it compiles Make sure that you don't have this data racist You can't modify something When somebody else is reading and stuff like that So that's what it gives you This kind of guarantees You couldn't use this algorithm in fact This algorithm depends on the fact that you can't Modify something when somebody else has a reference Which is guaranteed by the compiler And this is actually It's called Giga updates per second So it's to test the random access memory Actually And this is comparing against the Message passing interface MPI I think is a classical C interface For message passing MPI doesn't share anything right So it's This is testing mainly the memory updates With MPI You don't use MPI on single machine With 8 cores Yeah, that's true probably You use all open mp Then probably just Okay This is Pony 1.0 Different versions of ponies are But all this code is open source You can run the benchmark yourself Okay So I think the interesting thing here To take away is basically The combination of this pervasive Framework, so you use it also for GC By sending GC-specific Messages to updates The owning actor So the two concepts, one is the implicit ownership Which is kind of obvious right, the actor that creates the Object owns it and then the other actor Sends it special messages to update And so on And you don't need any synchronization And there's no, it's because it's all done To the same messaging framework So you really utilizes framework fully There's no stop the world For years there's no special things So just purely based on messaging And yeah, you don't have to You just need to check your own tables You don't have to ask any global things Then you can do the GC And use it for the protocol Of the garbage collection And more stuff This is actually the iCoups Loops paper I think it's the implementation Compilation Of The languages, programs and systems It's a European Object-oranger languages So you can check out Pony Language It's kind of bare bones actually, I have it here I don't know too much about Poresies, but I don't think that's it Yeah, it's That's not, that's an orca There's no, apparently they have no icon Someone might be the first person to Create the Create the icon, right Half Pony, half work And then The colors I think here's some of the examples from The paper, look at the gups example This is an example of what For example, Pony code might look like If you're wondering So BE is the behavior Or the Asynchronous messages that you send And this is like Pony code, it looks a little bit Like Scala somehow, because of the way Because they do this Column thing, you know, like This is also statically typed of course Otherwise you couldn't prove the No database thing So it's statically typed and compiled To LLVM and then to Wavecode And it looks something like this Yeah, I think it looks weird to me All the try and end blocks Anyways Yeah, in case you're wondering what Because it's defined like actor and then you have These are your fields These are your like behaviors The asynchronous things Yeah, that's That's that Sorry, where was I Questions? Did there any? Oops, yes For Higher order messages Like Sending behaviors Yeah You can send lambdas so That much I know Which might be what I want to do You can send a lambdas So I think it's quite common to send a message a lambdas It's kind of like a callback So it's like after you do this Call that thing so that Yeah, so that's possible You can send lambdas I don't know why it's not scrolling Or this is the last one Those lambdas, I mean Are they proper lambdas? The closures which can have references To objects because that's what's Interesting, right? You know that closure is done lambdas Are no big deal You can of course, but it's again bounded by the property of this So in this language For example, I don't know if you know things like concurrent hash map For example, like in Java or you can have a hash map Which everybody modifies all the threads You can't program it in this language For one thing Because it's just not allowed by the type system You can't have one object that's Modified by multiple actors at the same time So that's just this allowed completely Not really There are different types of references Because the object doesn't cross the boundary But the object stays to the wall Yes, yes So you only pass a reference to A2 to 101 They get a reference From A1 to 101 So but can A2 pass this reference to A3? Yes, yes, of course But at only one time, there's only one reference To one object No, not really Because both A You have two references to A2 You have one from A2 I guess it draws it as all black lines But in reality there are like six different colors Of lines So it all draws it at the same kind of line But in reality there are different kinds Of arrows For example, I think it's fair to say There's only one actor that can ever Modify an object Yes That's correct So it's like You do two texts without two texts It's more like you have a dedicated Actor for writing Something like that Anybody It may not be A1 It may transfer this right to somebody else But when it transfers, A1 must destroy Its own rightable reference Because you kind of have two The universe kind of blows up So you have to transfer to some other actor It depends I got to transfer my right to Only one guy can have the time To write for those characters Actually when someone is writing In fact, nobody else can read it either Because you could also be inconsistent When you allow that Because in between writing To this guy, it doesn't matter Because every single act is an atomic So you have to write and read You cannot write and read at the same time Could be different actors If A2 was writing O2 Which is actually not possible in this case Then it's not possible that there's actually a path From A1 to O2 Because they could run simultaneously The behaviors could simultaneously execute But when you say you write O2 What does that mean? Because the reference is that it can change So if A2 changes O2 That just means it has an O2 prime And the arrow from A to A No, no, no As it changes one of the fields It's like a pair of Things It could have a pair of whatever It's not drawn here It could change one of the references to now It could change it to another object As an update Literally destructively update the field Of O2 But wouldn't let me model that Separate objects Yeah, separate objects O2 can have reference to O1 Yeah It's like a reference, right? But actually it doesn't matter in this case Because we don't count all these O to O references Because they don't write each other You need to count A to O references Because A to O you can write In some sense, yes You only care about the A to O references So that means there can only be one A to O reference One write A to O reference At one time For writing, yes But reading it, you can have multiple reading So how does it guarantee I don't see how it guarantees that It reads It's not in this paper and it's not in this presentation It's in a different article actually Talking about a type system Yeah, that would be a different topic So I don't want to go into that You could do that I think you can imagine You could do that in your program by hand If you're very careful when you're writing it It's just the compiler checks that you are careful Instead of you checking that I am carefully Moving this around without Yeah, that's better So the compiler checks for you, that's all When it can be done But it requires a bit too many Types of references, six types So I think the question in the community Is whether that's too many for people to Keep in their heads, six different types You probably need to convert between the types Because Yeah, it's So Okay What's up soon by Rust It's similar but different There are some types here actually that are not Representable in Rust I guess someone said that in Rust You build some of these ownership based By using Rust primitives But these are sort of inbuilt into the language So the six types of references Are built into the language But they actually kind of Shows that these six are all you ever need To talk about the references So they actually did a comparison with Rust In this paper, you can look at it They have some things that you can't represent In Rust I think But there's a higher cognitive overload To remember the six different types of references So these arrows as I said It's not just one kind of arrow Six kinds of arrows And it gets a bit crazy But I think one thing Interesting is worth checking out The repository is interesting in contributing to A language So mostly written in C There's some C++ That talks to the LVM backend But They're using a Google test library Also written in C++ But the main runtime and the compiler is written in C So if you're interested to check this out You can see how they actually do the scheduling Of the actors, they actually create Regular OS threads And schedule them and so on Pretty small active community I think right now It was a good time to get in If you're interested So I think this is a space where You have the actor model You have sending with no copies And you have the compiler Proving guarantees that you can never get into Kind of concurrent multiple state problems So it's a pretty interesting space I think they're trying to push this For financial applications But we'll see how that goes Right To understand that from the point of view Of a big cluster I think the distributed system is good But Out of consideration What could be the bottlenecks here What happens if you say Have a central node That sends the messages to everybody And then the central node Say Or Is Encumbered by the garbage collection From thousands So actually for this one This is purely on a single machine Yeah because that's basically What made COM so crappy What do you think about it COM Yeah yeah the I'm not familiar with it but I heard about it COM is a rev counter With inter process And that's actually one of the basic Decom Yes One of the basic failure modes It might be a big problem I have to go look it up It sucks because you have a process Dying and suddenly you have all these Unaccounted references Your reference count Can never go to zero That's where your memory just grew Oh I see Yes For a single application running Of many cores This makes sense I think if you want to have a cluster It becomes As soon as your cluster reaches Certain number of nodes No I mean as soon as it reaches two More than one Certain number more than one I think right now they are in a process Of working on the distributed version I mean two is not a big cluster Because you can finish computation When on two nodes In a reasonable time You have a thousand nodes Or ten thousand nodes It's statistically impossible to have The whole cluster working All nodes at the same time You need his propagation And divide by two You need to count the electrons Providing a lot I hear that People that have sufficient number Of nodes have basically One guy per say Hundreds So as soon as you have two Or robot As soon as you have just two machines Or even just two processes If one of them goes away Because of anything Not necessarily a hardware player But just any reason Then none of the invariance What I said Very quickly for two nodes It's not that painful It's not that painful It happens once a while There is a Qualitative difference Between running something on A thousand cores Even just two processes And the difference is that In two processes One of them can go away Two down the other Even if you have a thousand cores But if you have one process It's all or nothing And you don't care what happens So here we have A perfect system for like One machine One machine multiple cores But the number of actors They stay the same throughout You can create new actors Dynamically on the fly So the reference count They will suddenly just increase Everybody's reference count Will increase by one Not everyone Only those who have seen That before When you receive a message You got to construct some new slots For things that you have not No You don't have to If you never see those That's when you need to Account Actors are lightweight You can construct millions of them So that shouldn't be the problem You have millions of actors Interacting Of objects in between them Then your reference count Can also become Yeah, so I guess You shouldn't be sending every object to every actor That would be kind of a bad idea It's a limitation for the The number of actors Yes, of course The count they will grow As the size of the actors who have seen the object So if you have Many actors seeing many objects Then there will be a big overhead for this thing I'm not saying I think in practice it's not that common to do Like multi-cars or whatever In the actor system It's not gross But you It gives a certain trailer That there is the hidden component Of this algorithm is the type system Of the pony Yes A different type perhaps Another top But Just to mention for the distributed part Of pony There is a master's thesis For distributed pony Multiple machines How do you handle machine failures I think there's no paper on it But there's a thesis Sure Sure, I'll update it in the event Okay Alright, thank you for listening