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?