Here is the trace: http://minnow.cc.gatech.edu/squeak/3243
It is pipelining messages, but I don't have a proper event-loop, so it doesn't flush the connection buffers at the end of each vat turn - instead I flush every 10 ms. Also, the lack of an event loop results in no partial ordering guarantees. Proof of this is in the trace showing that the initiating side processes the second resolution before the first resolution (in the third chunk of messages).
regards, robert
At 03:21 AM 6/8/2003 Sunday, Rob Withers wrote:
Here is the trace: http://minnow.cc.gatech.edu/squeak/3243
It is pipelining messages, but I don't have a proper event-loop, so it doesn't flush the connection buffers at the end of each vat turn - instead I flush every 10 ms. Also, the lack of an event loop results in no partial ordering guarantees. Proof of this is in the trace showing that the initiating side processes the second resolution before the first resolution (in the third chunk of messages).
Rob, I don't have anything useful to contribute at this time, but I just wanted to say congratulations! This is fantastic!
Btw, this seems like a good opportunity to mention Dean Tribble's E-on-Squeak project http://www.eros-os.org/pipermail/e-lang/2003-May/008689.html , porting Kernel-E, and eventually E itself, onto the Squeak virtual machine.
---------------------------------------- Text by me above is hereby placed in the public domain
Cheers, --MarkM
Mark,
On Monday, June 9, 2003, at 12:43 AM, Mark S. Miller wrote:
At 03:21 AM 6/8/2003 Sunday, Rob Withers wrote:
Here is the trace: http://minnow.cc.gatech.edu/squeak/3243
It is pipelining messages, but I don't have a proper event-loop, so it doesn't flush the connection buffers at the end of each vat turn - instead I flush every 10 ms. Also, the lack of an event loop results in no partial ordering guarantees. Proof of this is in the trace showing that the initiating side processes the second resolution before the first resolution (in the third chunk of messages).
Rob, I don't have anything useful to contribute at this time, but I just wanted to say congratulations! This is fantastic!
thank you! Especially for your explanation on Redirectors: http://www.eros-os.org/pipermail/e-lang/2003-March/008632.html I was stepping through the animation like mad for several days. :)
I fixed the partial ordering by making every eventual process have the same priority and adding them to the end of that priority's linked list in the scheduler.
I am confused about when to send the GCExportOp, with the corresponding wireCount. ImportTable holds the far handlers to redirectors strongly, so they will never finalize. Additionally, it looks as if the redirectors in the exports table and their far handlers in the imports table never get lost, so they must be getting reused somehow.
Btw, this seems like a good opportunity to mention Dean Tribble's E-on-Squeak project http://www.eros-os.org/pipermail/e-lang/2003-May/008689.html , porting Kernel-E, and eventually E itself, onto the Squeak virtual machine.
It should be easy to stitch in this CapTP work using his references. Serialization remains an obstacle, since I am not using WOS, yet.
cheers, rob
Mark, I found the answers to my questions, so no worries about them.
On Monday, June 9, 2003, at 01:28 AM, Robert Withers wrote:
I am confused about when to send the GCExportOp, with the corresponding wireCount. ImportTable holds the far handlers to redirectors strongly, so they will never
actually, I learned that ImportTable holds a ProxyResolver, which in turn holds a weak reference to the Proxy. When the Proxy goes away, it's finalization will need to trigger the resolver to either send a GCExportOp, if the Proxy is an Import, or drop the Question. It does leave the ProxyResolver in the imports table at the same ID.
finalize. Additionally, it looks as if the redirectors in the exports table and their far handlers in the imports table never get lost, so they must be getting reused somehow.
The processing of the GCExportOp will knock the entry out of the exports table. It is the ProxyResolvers in the imports table which never get removed once they are added. As new pass-by-proxy objects get published in the exports table, that table reassigns freed IDs. These reassigned IDs happen to correspond to the existing ProxyResolver in the Imports table, which are reused. Since imports are used in processing every remote message send, for the message send's redirector, these import entries can get reused a lot. :)
Rob
squeak-e@lists.squeakfoundation.org
-
Mark S. Miller -
Rob Withers -
Robert Withers