I want to point out that the above does not account for Java byte/word alignment in memory. Since our actors do not use unmanaged memory we are subject to how Java decides to align variables in memory. This could add another several bytes, but probably not many. I'd estimate that this could push the default size above 300 bytes, possibly 320 bytes or so. Adding to a large name string could push 384 bytes, or just short of 400 bytes.
We have not made any attempt to improve this. I have felt that my use of variables has been somewhat wasteful, but I don't want to try to tune the memory usage unless I know that it will make a big difference. There are several things we can do to improve that if we decide to.
FiberMailbox. This would be experimental until fibers are production worthy. I was told by a loom committer that perf would not be good for some time so I haven't bothered going to the trouble. Plus I don't want unnecessay dependencies.
@/all Today we released v1.1.0 GA of the vlingo/PLATFORM. This release includes vlingo/streams, our implementation of Reactive Streams. The docs are available now as are the binary artifacts. This is a growing component and will be enhanced with new features, specifically around types of
Sink implementations, as well as typical functional sugar.
@VaughnVernon couple more questions:
How will RSocket support be incorporated with streams (and wire) - use case I am looking towards is creating RSocket channels end to end between actors residing in remote client-side and server-side nodes? The client-side may use another RSocket library in any supported platform. Client-side actor > RSocket Reactive Streams > Server-side actor - thereby allowing actor to actor actor-messaging between different client-server actor lib through standard reactive streams.
Is thread-starvation a possibility in vlingo/actors like it is a problem in Akka if any actor blocks a thread due to some computational task or use of any blocking library?
Mailboximplementation. The concept used by the
Dispatcherbased on a thread pool executor. You set the maximum number of threads or provide a factor (e.g. 0.5 or 1.5) to multiple with the total number of processor--hyper thread--to determine the pool size. There are a few different dispatcher algorithms that could be used and we will add these based on user need (not nice-to-have suggestions that are never used). The
arrayQueueMailboxis a MPSC ring buffer with a single dedicated Java thread meant for every high throughput, generally 18-20 million messages per second. You choose the ring size. Note this uses pre-allocated message elements, and thus can be memory intensive, but also greatly reduces GC overhead on high throughput.
Schedulerin both vlingo-actors and Akka is used for timers that schedule one or continuous future signals to an actor. The term used for delivering messages to actors on threads is called dispatching. Erlang/BEAM doesn't assign O/S threads to processes in the way that Java does. It sort of implements a virtual O/S of its own, which enables all kinds of different ways to control fairness. Think of how Un*x and Windows operating systems how by literally interrupting execution of a process on a thread and giving that thread to another process. So a JVM is interrupted by the O/S in mid execution of some/many code paths. That's what the BEAM does to it's own processes (and yes, the O/S still interrupts the BEAM).