Subject: referee report Resent-Date: Thu, 30 Sep 1999 23:16:58 -0400 Resent-From: Geoffrey Fox Resent-To: p_gcf@npac.syr.edu Date: Mon, 13 Sep 1999 15:44:01 -0400 From: Maurice Herlihy To: gcf@npac.syr.edu Here is one referee report --- others will follow. Maurice =-=-=-=-=-=-=-=-=-=- referee report Design of the Kan Distributed Object System This submission is a comprehensive report on the Kan Distributed Object system, giving a thorough analysis of various performance aspects of the system. Kan encompasses a variety of mechanisms, some familiar, so less so. The paper is well written, and should be of substantial interest to the Java community. The remaining remarks are suggestions for improvement. The paper seems a little long, and could probably be trimmed in several places. (The related work section, for example, seems to ramble a little). The description of the implementation is pretty complete, but I was left with some questions about the rationale. Is Kan intended primarily for one-shot applications (eg,start up some threads, invert a matrix, and shut them down) or for long-lived applications (eg, web caches), or both? The socket structure and assigning consecutive integers to nodes suggest a one-shot orientation, but other comments suggest that Kan can be used for long-lived applications. A brief discussion would be enlightening. I am not sure what happens in Kan if a guarded transaction's condition involves one or more remote objects which may themselves require locks --- presumably these locks are acquired on behalf of the transaction, but are then released and reacquired if the condition fails? Can guarded transactions be nested? Does the wound-wait-recover algorithm guard against deadlocks in this case? With nested transactions, it is possible to write programs that always deadlock (or is it?). How does the wound-wait-die scheme work then? Is two-phase commit used only at the top level? Are orphans an issue? (An orphan is a transaction that observes an inconsistent state before aborting). Does the transaction model include persistence? I didn't understand how to do pointer swizzling in variables without modifying the JVM. Is there a level of indirection here, or does the compiler preprocessing deal with this? More technical detail here would be welcome.