doc/reviewer.comments.txt

   1 From: Etienne Gagnon <gagnon.etienne_m@uqam.ca>
   2 Subject: IVME 04 Author Notification
   3 To: Adam Megacz <adam@megacz.com>
   4 Date: Thu, 22 Apr 2004 13:00:54 -0400
   5 Organization: UQAM
   6 Resent-From: nobody@nowhere.com
   7
   8 Dear Adam Megacz,
   9
  10 I am pleased to inform you that your paper (#17):
  11
  12         "Complete Translation of Unsafe Native Code to Safe Bytecode"
  13
  14 has been selected for publication and presentation at IVME 04.  This
  15 year a total of 15 papers were submitted and of these 6 were selected
  16 for publication.
  17
  18 Below please find the reviewers' comments.  Please incorporate any
  19 suggestions made by the reviewers and prepare the final version of your
  20 paper according to the ACM SIG Proceedings Templates at
  21         http://www.acm.org/sigs/pubs/proceed/template.html
  22 Please follow the SIGS style carefully.
  23
  24 Please note that papers should normally be limited to 8 pages, including
  25 figures, bibliography, possible appendixes, etc.  Please ask for permission
  26 by email (gagnon.etienne_m@uqam.ca) if you need more than one or two
  27 additional pages.
  28
  29 IMPORTANT TASKS TO DO
  30 =====================
  31
  32 ** The electronic final camera-ready version is due on (strict deadline)
  33 Monday May 10th, 2004.  You must send your paper as attachment to an email
  34 message to gagnon.etienne_m@uqam , in a compressed .zip or .tar.gz archive
  35 which should include both of the following:
  36 - A PostScript or a PDF version of your camera-ready paper.
  37 - The source version of your document (LaTeX, Microsoft Word), suitable
  38         for modification (to add heading/footing information such as line numbers).
  39         *** If you used another software, please inform us of this fact by replying
  40         to this message as soon as possible.
  41
  42 ** You must also print, fill and sign the copyright form attached to this message
  43 and send it by mail to:
  44
  45         Prof. Etienne M. Gagnon
  46         Departement d'informatique
  47         Universite du Quebec a Montreal
  48         Case postale 8888, succursale Centre-ville
  49         Montreal (Quebec)
  50         Canada  H3C 3P8
  51
  52
  53 Do not hesistate to communicate with me as soon as possible if you have any
  54 problem with formating your paper according the the ACM SIGS style.
  55
  56 Regards,
  57
  58 Etienne Gagnon
  59 Program Chair
  60 IVME 04
  61
  62 -------------------------------
  63
  64 Legend
  65
  66 1 Strong Reject
  67 2 Weak Reject
  68 3 Undecided
  69 4 Weak Accept
  70 5 Strong Accept
  71
  72 -------------------------------
  73
  74 Appropriateness to the Conference:      4
  75 Originality:    4
  76 Technical Strength:     4
  77 Presentation:   4
  78 Overall Evaluation:     4
  79 Comments
  80
  81 An interesting paper demonstrating the translation of MIPS R2000 binaries to safe JVM bytecodes.
  82
  83 The paper has some novelty value, since everybody knows that in theory an arbitrary native code binary could be emulated in this way, but nobody seems to have done a complete job.  Thus the paper answers the existence question, and provides some implementation details.  Of course a remaining problem is the issue of emulating the runtime/sys-call interface of the native binary.
  84
  85 The discussion of the techniques by which the quality of the bytecode representation of the program may be improved was helpful.
  86
  87 However, a wider range of measurements of performance would have improved the paper.  Some discussion of the theoretical limits to performance using such a compilation path would have been of interest also.
  88
  89 There are a number of typos in the paper as presented.  A careful proof reading would be in order before final submission.
  90
  91 Finally, there are a host of unanswered questions regarding the practical use of such techniques. Unsafe code is, well, unsafe.  Users of managed frameworks expect a certain degree of safety.  It seems that there are several levels of insecurity here.  Type violations in the native code should be bug for bug equivalent in this framework.  Stray pointers presumably lead to array bounds violations in the JVM (?).  So what happens with unsafe use of the system call interface?  Is this trapped in the NestedVM runtime? Is it trapped inside the Java sandbox, or does it require high privilege setting and wreak its damage anyhow?
  92
  93 -------------------------------
  94
  95 Appropriateness to the Conference:      4
  96 Originality:    2
  97 Technical Strength:     4
  98 Presentation:   4
  99 Overall Evaluation:     4
 100 Comments
 101
 102 Interesting paper to read.  There are some typos which should be fixed, many of which a spell-checker should catch (my favorite is "highlym odular" on page 2).
 103
 104 I'm not convinced that the MIPS ISA and the JVM have a "close similarity" (Section 4.1), but one could argue that they have "similarities" as they go on to explain.
 105
 106 The citation to the JLS needs fixing, as does capitalization in a number of references.
 107
 108 Some data needs to be shown on the size of translated binaries.
 109
 110 What about code that uses non-libc libraries?
 111
 112 A C to Java translator was done in 1996 which bears a lot of similarity to this work (including the big array to represent memory).  See C. W. Fraser and D. R. Hanson's "A Lean Retargetable C Compiler," 1996, at http://www.cs.princetom.edu/software/lcc/doc/lean.pdf.  The work by Fraser and Huelsberger is the C to Java translation.
 113
 114 -------------------------------
 115
 116 Appropriateness to the Conference:      5
 117 Originality:    5
 118 Technical Strength:     5
 119 Presentation:   4
 120 Overall Evaluation:     5
 121 Comments
 122
 123 I really liked this paper (the best one in my batch). However, I would have preferred to see more technical detail instead of the blurb in Sections 2 and 3, which wastes almost 1 1/2 pages. This space could be spent much better on a deeper technical discussion.
 124
 125 Also, I am a bit sceptical of the results, which look almost too good. I cannot imagine that translating MIPS instructions into Java of the sort shown really only has 10x worst case overhead. I would have expected more like 1000x overhead... A further discussion would be welcome.
 126
 127 But overall, this is very interesting and novel.
 128
 129 -------------------------------
 130
 131 Appropriateness to the Conference:      5
 132 Originality:    4
 133 Technical Strength:     4
 134 Presentation:   4
 135 Overall Evaluation:     4
 136 Comments
 137
 138 Nice paper, well-presented, but a little light on details.
 139
 140 You chose MIPS because it was likely to be the easiest.  Have you thought
 141 much about x86, Power, etc.?  How much harder would it be to do
 142 this for other ISAs?
 143
 144 Were there any peculiarities of the JVM that were gratuitously
 145 difficult to deal with?  I would have expected the lack of
 146 unsigned int types to be a pain.
 147
 148 I'm guessing that NestedVM can't handle multi-threaded apps;
 149 please mention this.  (I note that bug-for-bug compiler
 150 compatibility is very hard, perhaps impossible to achieve
 151 for multi-threaded apps, because the memory models of the
 152 original machine and the JVM are unlikely to be the same).
 153
 154 There is no mention of the work on binary translation to bytecode
 155 done by Cifuentes et al, (see, e.g., the paper in Computer, Mar 2000,
 156 or the paper in the Workshop on Binary Translation (1999)).
 157
 158 You should make
 159 a pass with a spell checker.
 160
 161
 162 [2. application/octet-stream; copyright_form.pdf]...
 163