On May 12, 2009, at 2:42 PM, Michele Simionato wrote:

On Tue, May 12, 2009 at 1:15 PM, Abdulaziz Ghuloum <[email protected]> wrote:
I hope this makes it clear so that what Ikarus does is not
mislabeled "lazy".

You are saying that Ikarus determines if a library is used or not
statically, whereas Java does it dynamically at runtime, right?

Very close.  When the Ikarus expander encounters a variable
reference, it knows two things: the expanded library instance
in which the variable is defined, and the location in which
the value is stored when/if that library is instantiated.
Cool so far?  Java does the same statically: it resolves the
variable reference to a location and a defining class during
bytecode compilation (think of it as macro expansion since
each Java statement is expanded to the equivalent JVM byte-
code).

Now you have a library (or any piece of code really) that
contains many such variable references from many libraries.
What Ikarus does is to ensure that these libraries are
instantiated (and therefore, all exported variable locations
are filled with values) *before* the code that contains the
references is run.  This allows ikarus (among other things)
to compile a variable reference to a single machine
instruction that fetches the value from the memory location.

If we want the Java instantiation semantics, we can keep
everything the same but compiling a variable reference cannot
be this simple since at run time, the library defining the
variable may not have been initialized yet.  Thus, the code
for variable reference may either account for this, e.g.,
referencing x from (X) would translate to something like:

  (begin (invoke-library! '(X)) (mem-ref 'x-location))
or
  (let ([v (mem-ref 'x-location)])
    (if (uninitialized-value? v)
        (begin (invoke-library! '(X)) (mem-ref 'x-location))
        v))

One can of course play tricks with the runtime system (like
protecting the page in which x is located, trapping segfaults,
unprotecting the page, calling the initializer from the trap
handler, then resuming the code where it left off).

Or one can do some extensive analysis as to eliminate these
checks as much as possible when the compiler can prove that
some libraries would have to be invoked at some point and
thus the check can be eliminated.

Or one can just run the code in an interpreter and wait until
code becomes "hot" and many variable locations are initialized
and only then compile the code to machine code.  This is what
Java HotSpot does (in addition to a gazillion other things).

Either way, it's all doable in Scheme.

Aziz,,,

Reply via email to