Re: [Sablevm-user] Technical Report

[Etienne M. G. <eg...@j-...>]

John Leuner wrote:
> 
> My first comment is on the use of a threaded interpreter. As I understand
> the bytecode array will no longer be one-byte instructions followed by
> their operands, but instead will consist of 4 byte pointers to the
> implementation for that instruction.
> 
> Isn't this terribly space inefficient? Wouldn't this require 64bits per
> pointer on a 64-bit machine? I say this in light of the pressure put on
> memory by the JIT and optimising process, this would make the pressure on
> memory even worse.


The pressure on the memory is = sizeof(void *) X bytecode buffer size

This is greater on a 64 bit platform.  But presumably, a 64 bit platform
has plenty of memory, and this is likely to be much less than the JIT
compiled size of bytecode.  Some of this space could be saved using
simple comptression techniques, but you should also take into account
the importance of data alignment in memory.  If you misalign data, your
programs are likely to suffer from the overhead of extracting it from
memory.  On some RISC platforms, this overhead can be significant.

I think that a compromize, on 64 bit platforms, is to group bytecode
parameters within words, if possible (as you can fit 2 Java "int"s into
a single wors).  But, addresses are 64 bits, so every bytecode will be
effectively represented by a whole word.

 
> You also say "The advantage of unmapping memory, relative to simply
> freeing memory (using malloc/free) is that unmapped pages need not be
> dumped to disk by the VMM system when they are to be ejected from RAM".
> 
> I don't really understand this line? Do you mean that instead of
> malloc'ing a 5M heap (which will be regarded by the VMM as useful data),
> you can selectively allocate the pieces being used by the heap?


I have had discussions about this with some people.  It might not be
such a good idea, after all, as (1) unmapping memory is an overhead if
no memory is being swapped to disk, and (2) if the VMM starts swaping
memory to disk, then it is already too late, i.e. your application
becomes dead slow.
  
So, the basic principle here is to keep a heap size that fits your RAM,
in which case, unmapping is unnecessary.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableVM:                             http://www.sablevm.org/
----------------------------------------------------------------------