[e-lang] [ANN] AsyncObjects 0.1.0 (alpha)

Sun Apr 29 13:40:50 EDT 2007

On 4/29/07, Mark S. Miller <markm at cs.jhu.edu> wrote:
> This is exciting. I've just read the first 10 pages of your user's guide and
> skimmed the rest. Are the following first impressions sensible?
>
> The biggest differences between AsyncObjects and ref_send are:
>
> * ref_send builds on Joe-E, not Java, and so starts with a sequential
> object-capability language. ref_send itself conforms to and supports
> capability discipline including support for writing defensively consistent
> abstractions.
>
> * AsyncObjects builds on and potentially assumes the full Java SE language,
> though it started within a particular "foundation profile". AsyncObjects is
> not intended to support mutual suspicion among objects in the same address
> space. AsyncObjects assumes the programmer has some familiarity with Java
> threading concepts, and provides much flexibility in how they may be mixed. It
> is up to the programmer to avoid mixing threads and event loops in unsafe ways.
>
Yes. However some utility classes are provided to make such mixing
safe one. Also when using the framework, the need to create such code
is much lesser. AsyncObjects is targeted to simplify life of Java
programmers. It is not a goal to restrict code that is being designed.

Foundation Profile is a Java ME platform that is a strict subset of
J2SE 1.4. It is available on some smart phones and PDAs.

> * ref_send, though neither distributed nor persistent, is designed to support
> distribution and persistence (as demonstrated by the Waterken server) with
> only minimal additional restrictions imposed on the ref_send programmer. I
> couldn't tell whether this was also one of the hidden goals of AsyncObjects.
>
There might be a support for this in the future. Currently, the
framework is focused on providing mechanisms for safer communication
insider a single JVM.

I also do not believe in the orthogonal persistence. Some activation
mechanism might be added and it might be integrated with remoting
mechanism. However it will not be orthogonal. See my rant thoughts on
the issue at http://constantine-plotnikov.blogspot.com/2007/02/software-system-longevity-paradigms.html.

Another issue is that databases expect transactions to be as short as
possible. And they have a reason to expect it, because their
concurrency model is based on row and table locking. Having
asynchronous database drivers might break these expectations as they
could introduce delays during transaction, and every millisecond of
transaction duration matters for database scalability.

> * With AsyncObjects, you've done the hard work of understanding and wrapping
> the Java NIO library, in order to provide efficient asynchronous IO to your
> event-loop programming library.
>
>
> In many other ways, as you say, these systems are similar. For ref_send, the
> safety issues cannot be compromised. If our safety requirements are not
> incompatible with your goals, perhaps we can find a way to merge efforts?

Multi-threaded programming Java currently is a very complex. And
having a library like AysncObjects that lessen the pain is a good
thing. So I would like to support plain Java SE support. However,
efforts could learn from each other and even use each other. Comparing
usability and expressiveness of both approaches could be useful as
well. Use of services developed for AO from ref_send like NIO support
should cause any problems and AsyncObjects might be a good layer for
implementing system-level services that need to talk to Java SE too
much anyway. Also from what I have seen, it might be possible to run
ref_send processes over AsyncObjects vats.

After migration to Generics, I plan to offer the project to
Apache.org. Support for plain Java SE, including a bit tamed
multi-threading hell is a critical for the project.

>  > From what I have seen ,
> > AsyncObjects are somewhat close to E syntax than ref_send.
>
> The only thing I was able to spot was the when syntax. Did you have something
> else in mind?
>
1. The core library model is simpler. ref_send model looks
overengineered comparing to E. There are too much classes without a
clear purpose. Possibly they are all needed to and serve some purpose.
But reading javadocs left me puzzled. Samples do not make things
clearer either. A tutorial that explains how to concepts play out
together would help. It would be interesting if you would implement
the same interaction scenarios as I have done in my developer's guide.
It can be used to compare usability of the framework.

2. The component developer is aware of the vats when using
AsyncObjects. However the components rarely work with them directly.
They are in the base class acquired using Vat.current() method during
creation of the object and this vat reference is used by the
asynchronous facet object to dispatch events. It is also possible to
create an event and to dispatch it the current vat. This behavior is
similar to behavior of E that allows eventual sends in the current vat
for any object. ref-send requires some manual event queue management.

3. A promise could be used to invoke methods on the object to which it
will resolve. There is a willBe method that creates a buffering proxy
from promise.

4. There is difference in AsyncObjects between eventual invocation and
immediate invocation. Eventual invocation is done over asynchronous
facet that is got using export() operation. ref_send seems to enqueue
events explicitly . However immediate invocations might be made on the
object itself. Note that a similar mechanism could be implemented for
ref_send. It would be just required to pass Eventual instance to new
asynchronous objects and to utility classes. I use ASM toolkit for
code generation of proxies, however there is a fallback implementation
that uses java.lang.reflect.Proxy. So a similar model can be
implemented for ref_send as well.

>
>
> > Due to
> > historic reasons the framework is compatible with JDK 1.4.x except for
> > some samples, so generics were not used. A next version will likely
> > support generics.
>
> E-on-Java is also in 1.4. Joe-E/ref_send/Horton is my first experience with
> Java 1.5 and generics. I must say I have mixed feelings about Java generics.
> Even after months of occasional hacking, I find I still cannot predict whether
> a code fragment I'm about to write will pass the Java 1.5 static type checker.
> When it doesn't, I often don't really understand why not. Instead, I find I
> fiddle with it until it does. This is partly a failure of discipline on my
> part, but...
>
There was already a functional version that used generics. However,
there was a chance to use the project on embedded server platform that
had JVM only with CDC Foundation Profile 1.1 support, so new version
was created that used only features of Foundation Profile 1.1.

Also it actually very easy to reason about generics in Java 5 if one
remembers a simple truth. Java does not have generics at VM level. So
code rejected by static type checker is the code that that requires VM
to be aware of the actual arguments of generic classes.

> In any case, this is a source of complexity that everyone in the Java world
> will get used to, so I agree that we should to.
>
I have a rant about generics at
http://constantine-plotnikov.blogspot.com/2007/02/java-5-vs-net-20-generics-past-vs.html

>
> > This framework can be also interesting to E as it implements All, Seq,
> > Any, and Using syntax extensions that I have proposed earlier as
> > utility classes. See developer's guide and samples for it.
>
> Could these all be expressed similarly in ref_send as well? (I suspect so.)

I see no problem with ref_send. They just use When class inside and
these utilities is one of major reasons why I think that AsyncObjects
is interesting for ref_send. For E they could be supported even more
efficiently using syntax extensions, making E even more attractive
distributed computing language. They are just shortcuts for
when/catch/finally. AsyncObjects implementation is a proof by
construction that such implementation could be done with reasonable
efforts and it can be used as template for ref_send and E.

>
> > The framework has a functional NIO wrapper. See the samples directory
> > where there are some trivial internet services implemented using it.
> > The directory scripts contain windows cmd scripts that launches them.
>
> Yes, wrapping NIO is interesting. It would be quite cool if we could find a
> way to use your NIO wrapping safely from within a Joe-E/ref_send program.
>
Actually, making NIO wrapper was quite simple after basic mechanisms
were in place.  Also BinaryData and BinaryDataBuilder classes created
to support IO operations are immutable. There is BinaryDataNIOUtils
class that somewhat breaks its encapsulation, but these operations
could be implemented in safer way.

Constantine