sablevm-user — SableVM user mailing list

[Fwd: Re: [Sablevm-user] JIT integration]

[Andrew P. <apu...@ac...>]

Forwarded to Sablevm-user.

-------- Original Message --------
"Etienne M. Gagnon" wrote:
> So, in conclusion:  I am open to accept your contribution if you can
> verify that you wouldn't be infringing any intellectual property.

I spoke with a gentleman in our legal department today. In short, I
am clear of Sun's Research Use license as Java and JVM related
development has not been and will not be part of my duties. I have
also spoken with my manager, who sees no problem in excluding me from
any potential future Java related projects. 

Moreover, there is no question that JIT and JVM/JIT integration work
that I do can be asserted as "clean room", because NAI is not in
possession of any Sun JIT technology. Now that I have specifically 
arranged through my management to NOT participate in any present or
future work with Sun's intellectual property, I am clear of any
contracts the company may subsequently enter into.

I'm willing to state this "publicly" on sablevm-user if you would
like.


Andrew Purtell
from home -- apu...@ac...

Re: JIT optimization framework (was: Re: [Sablevm-user] bug report...)

[Andrew P. <apu...@ac...>]

Argh. Please disregard the Reply-To. 

 
Andrew Purtell
from home -- apu...@ac...

Re: JIT optimization framework (was: Re: [Sablevm-user] bug report...)

[Andrew P. <apu...@ac...>]

John Leuner wrote:
> Also make sure you download the jit (it's a separate module called
> cavalry).

Thanks... Didn't have that yet.
 
> I'm a bit sceptical about making the JIT compatible with a range of
> VMs (like the classic VM), because there are so many VM-specific
> optimisations to be made. But I love the idea of modularisation and
> flexibility.

I think the essential idea is a framework where one can write a "plug 
in" transformation that can be run on a number of VMs, if it is 
something that can be performed at a high enough level. It is true that
those kinds of things alone are not enough to produce the best 
attainable code for a particular environment, but that is not a problem
as a particular VM's JIT (hopefully) would know a few tricks about 
optimizing for the local environment.

>> I'm investigating if that status also applies to work with Java in
>> general.
>
> I'm not sure I understand the last line?

My employer (NAI Labs) cannot claim "clean room" status and I need to
determine if there is a legal distinction between my role as an
employee of the company and my personal projects.
 
> I didn't want the overhead of any other framework, compiler, assembler
> etc. (If you haven't already, I urge you to read about IBM's jalapeno
> JVM, for the PPC
> http://www-4.ibm.com/software/developer/library/jalapeno/index.html
> ).

Thanks.
 
> I initially wanted to do a little bit of optimisation (such as register
> allocation), but was so depressed with the IA32's pitiful registers and
> different instructions for addressing the different sets of registers (MMX
> etc) that I decided to leave that for later.

Yes, that is why it is much more fun to work with the Alphas, even
though producing code for them is actually harder (w.r.t. instruction
scheduling).

> >   - Convert bytecodes into register transfer lists, mapping values on
> >     the operand stack to symbolic registers.
> 
> And it would be wonderful if this could be easily modified for different
> architectures.

RTL form itself is agnostic about machine targets, because all
registers are symbolic and all are assumed to be capable of holding
the largest (or smallest) integer and real values expressible in 
code. This leaves a lot of work for a register allocator when it
comes time to generate native code, though.

However, practical implementations still need to consider machine-
dependent issues during all phases of compilation -- CSE and constant
propagation, for example, need reasonable limits on the number of
temporaries generated. What is reasonable of course depends on the
target.

An OpenJIT-style optimization framework, then, needs to provide 
target specific information in a generic manner -- e.g.

	if (number_of_temporaries >= platform.max_available_regs())
		/* prune temps */
 
> What's interesting is that I haven't look much at the code that the java
> compilers produce. From many casual glances at bytecode however, I think
> there are quite a few simple optimisations which aren't performed.

I think most JITs are invoked indiscriminantly and are therefore
limited by the need for speed to variations on simple bytecode to 
native code mapping. Etienne would like to see a VM invoke a JIT for
a particular method only if there is a clear benefit. I think that's
the only way to go if the JIT will be spending time aggressively 
optimizing the result.
 
> >     - Code straightening and jump threading.
> 
> What is this?

Code straightening and jump threading both have to do with improving
how branches are taken through the code. Code straightening takes
the code over what appears to be the most likely path of execution
through a procedure and arranges the corresponding basic blocks
sequentially -- so the most likely case is the fall through case.
This means that it is more likely than not that prefetched 
instructions can be executed rather than discarded. Jump threading
looks at branch targets. For example, if the target of an 
unconditional branch is another unconditional branch, then the
natural thing to do is make the first branch point to the second
branch's target. As another example, branches which point to the
very next instruction (commonly a result of other optimizations) can
be simply removed. Cases involving conditional branches are more
interesting.

> Yes, the whole issue of having the compiler substitute special code for
> marked methods is also something I'm very keen on. Specifically I want to
> avoid the overhead of native method calls for doing things like file IO
> etc.

You should look at the work the Jaguar project has done in this area:
http://www.cs.berkeley.edu/~mdw/proj/jaguar/
 
> Yes, again there is a need for an initial translator which is very fast,
> but which will be superseded by a more advanced version at a later stage.

Yes, or a VM with a fast interpreter which invokes the JIT 
selectively.
 
> Remember that objects in the java heap move around. (I suppose you could
> pin these down).

Hmm. Marking code object storage involatile is one option. Creatively
fixing up what code can't be made position independent as required
is another. I haven't thought too much about this yet, but I certainly
will be. :)
 
> It's so sad that efforts like IBM & Sun's compilers have to be closed
> source.

I agree. Or in Sun's case, what source is released comes with a
"problematic" license.
 
> Yip, and if you're willing to bend the rules a bit you can also cache
> field accesses. I haven't looked much at what optimisation is possible
> from an OO point of view, but there is definitely a great potential for
> speedup in this area.

Etienne worked in the past on a Java optimizer that did various OO
optimizations -- e.g. inlining, transforming virtual calls to static
ones, etc. (http://www.sable.mcgill.ca/soot/) I'm looking at this as
a starting point.
 

Andrew Purtell
from home -- apu...@ac...

Re: JIT optimization framework (was: Re: [Sablevm-user] bug report...)

[John L. <je...@pi...>]

> > Unfortunately I had to stop working on this project for two months
> > due to a sports injury but I've recovered enough to carry on working 
> > now. 
> 
> That's unfortunate. I'm sorry to hear that.

I'm sure you can appreciate (as a programmer) what it's like to not be
able to type properly for 2 months! But any sports injury is ultimately
self-inflicted, I'm very glad I'm not a professional sportsman (eg rugby,
soccer etc).

> > If you're interested in the code or just discussing jits
or > > whatever, just let me know. 
> 
> Both. :)
> 
> I've downloaded your 0.07 source and I'll have a look next week when I 
> have time.

Ok. I'll prepare some quick docs to help you build it, I've been swapping
build systems lately and things are not yet finalized in that area.

Also make sure you download the jit (it's a separate module called
cavalry).
 
> As for my interest in JIT technology, I've been inspired by the
> OpenJIT project (www.openjit.org) to implement a JIT framework where
> the JIT, code generator, and optimizer are all first-class Java
> objects. Normally I am not taken to duplicating the work of others,
> but this is cool technology that really should be available under the 
> GPL.

I managed to get through to the page today, it does look very interesting.
I'm a bit sceptical about making the JIT compatible with a range of VMs
(like the classic VM), because there are so many VM-specific optimisations
to be made. But I love the idea of modularisation and flexibility. 

> I have not looked at the OpenJIT source, so this will be a 
> "clean-room" effort in the respect. I'm investigating if that status
> also applies to work with Java in general.

I'm not sure I understand the last line?

> I note that you generate assembly text and then compile it. 

Let me quickly explain my strategy. When I first started this project (the
translator), I was just playing around with ideas, it was essentially a
prototype which would help me get a feel for what I was doing and tell me
whether I wanted to take this further. 

Originally I generated machine code directly for each bytecode (literally
putting the binary bytes into a stream). The reason I took such an extreme
approach is that I wanted to have an intial translator which could
transform the bytecodes into machine code as quickly as possible. 

I didn't want the overhead of any other framework, compiler, assembler
etc. (If you haven't already, I urge you to read about IBM's jalapeno JVM,
for the PPC
http://www-4.ibm.com/software/developer/library/jalapeno/index.html
).

So after I had played with that a bit I decided I liked it and would try
some more stuff. I wrote an IA32 assembler which then allowed me to compile a
far greater amount of bytecodes. At the moment I'm busy finishing this
round of prototyping. 

For me this was very much a way of getting acquainted with the issues
involved (especially wrt to assembly and the interface with the jvm). I
initially wanted to do a little bit of optimisation (such as register
allocation), but was so depressed with the IA32's pitiful registers and
different instructions for addressing the different sets of registers (MMX
etc) that I decided to leave that for later.

>I was
> thinking of doing something more along the lines of the following:
> 
>   - Partition bytecodes into basic blocks while building a control
>     flow graph.
> 
>   - Optionally run the standard Java code safety verification process, 
>     if this has been requested, e.g. "jvm -verify ..."

This definitely has to be present in a final version of any JVM. What is
also needed is to gather information for doing precise-GC. I don't do this
yet, but Ettiene has (or is planning to have) it in Sable.

>   - Convert bytecodes into register transfer lists, mapping values on
>     the operand stack to symbolic registers.

And it would be wonderful if this could be easily modified for different
architectures. 

>   - Hand off the RTL to "plug-in" optimization modules. What
>     optimizations are actually performed depend very much on how 
>     quickly I can get them to operate. Some classic optimizations are
>     very time-intensive. Initially I was thinking:
> 
>       - Constant folding, constant propagation, copy propagation, and 
>         value numbering.

What's interesting is that I haven't look much at the code that the java
compilers produce. From many casual glances at bytecode however, I think
there are quite a few simple optimisations which aren't performed.

>     - Code straightening and jump threading. 

What is this? BTW I don't regard myself as a "compiler person", I'm
generally interested in systems software and this area was one of many I
decided to play with while deciding where to put most of my research
effort. But the way it's going it looks like this will dominate my time.

>       - Common subexpression elimination (maybe).
> 
>       - Dead code elimination (maybe).

I'm don't have enough experience to know how costly these are versus the
others. It would be really great to get an idea of those costs and mix it
with profiling data to produce a very flexible solution.

>       - Replacement of certain bytecode patterns with precooked 
>         assembly templates, e.g. for x86:
> 
>             aload $value; invokevirtual "ntohl" ->
>                 asm ("bswap %0" : "=r" (value) : "0" (value))
> 
>             aload $value; invokevirtual "ntohs" ->
>                 asm ("xchgb %b0,%h0" : "=q" (value) :  "0" (value))
> 
>         or for Alpha:
> 
>             aload $value; invokevirtual "ntohs" ->
>                 asm ("insbl %2,1,%1; extbl %2,1,%0; or $2,$1,$2"
>                      : "=r"(t1), "=&r"(t2) : "r"(x))

Yes, the whole issue of having the compiler substitute special code for
marked methods is also something I'm very keen on. Specifically I want to
avoid the overhead of native method calls for doing things like file IO
etc. 

>   - Finally, hand over the munged RTL to an emitter which emits native 
>     code directly into space allocated on the Java heap. The emitter 
>     would assign real registers from symbolic ones using one of the
>     graph coloring algorithms. If that kind of thing is too expensive, 
>     there are alternatives.

Yes, again there is a need for an initial translator which is very fast,
but which will be superseded by a more advanced version at a later stage.

Remember that objects in the java heap move around. (I suppose you could
pin these down).

>   - For Alpha, a final peephole optimization pass is required because
>     instruction scheduling is very important for that platform.
> 
> All of that may be a bit much for a JIT, but whether or not that is
> true is what I want to find out. :)

Well you see that's exactly the issue that hasn't quite been addressed.
When I refer to a JIT I usually mean a
"everything-gets-compiled-before-excution" type system. That's easy to
implement but totally loses out on all the information available to the
compiler at run time. There's no way you're going to compete with a static
C/C++ compiler on CPU intensive stuff unless you spend a good deal of time
optimising those hot spots. Jalapeno is similar to openJIT in that it has
a few compilers to choose from. But I like the idea of really being able
to fine-tune the process.

It's so sad that efforts like IBM & Sun's compilers have to be closed
source.
 
> I would also want to add a module for converting variable references
> to immediate constants if the values are known at runtime. Perhaps
> there will also be an API for specifying such values. Code like this:
> 
>    if (case_a_is_true) {
>        /* a long block of code follows */
>    } else {
>        /* more code */
>    }
> 
> could be processed into:
> 
>    /* case_a_is_true is constant and always false */
>    /* more code */

Yip, and if you're willing to bend the rules a bit you can also cache
field accesses. I haven't looked much at what optimisation is possible
from an OO point of view, but there is definitely a great potential for
speedup in this area.

> Implementing all of the optimization framework in Java means
> everything is very dynamic and -- best of all -- can be self-
> bootstrapped into native code for maximum performance.

Bootstrapping is a thing of beauty and joy forever. 


John Leuner

Re: JIT optimization framework (was: Re: [Sablevm-user] bug report...)

[Andrew P. <apu...@ac...>]

"Etienne M. Gagnon" wrote:
> Soot has not only scalar optimizations, but also OO analyses/
> transformations.  

Soot does indeed sound like a good starting point. I'll read the
available papers -- and code, eventually -- with an eye toward
determining how expensive (in terms of time) the current set of
analyses and transformations are. 

I was going to put together something as simple and lightweight
as possible, but considering an aggressively optimizing JIT is
best applied selectively, there may be some wiggle room. Hmm.
I'm getting ahead of myself. Soot (or a subset) may well be
appropriate.

> You would think that Sun's HotSpot would not get any gain
> from such a static optimizer, but you would be wrong (as we have
> unexpectedly discovered); statically optimized class files were
> faster on many vms and many platforms (Linux,WinNT,...). 

I truly don't know anything about HotSpot, but I know people who
do, and I commonly hear it is constructed of rubber bands and
matchsticks. Those same folks claim IBM's JVM is much better.


Andrew Purtell
from home -- apu...@ac...

Re: JIT optimization framework (was: Re: [Sablevm-user] bug report...)

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

Adrew,

Andrew Purtell wrote:
> "Etienne M. Gagnon" wrote:
> > Have you looked at the "Soot" framework
> > (http://www.sable.mcgill.ca/soot/)?  ...
> 
> Thanks!
> 
> And now I guess I know where the name "SableVM" comes from...

To tell you a little more about Soot.  Soot has not only scalar
optimizations, but also OO analyses/transformations.  It does things
like changing virtual method calls into static calls (invokevirtual ->
invokespecial), changing interface calls into virtual calls, it also
implements inlining (which is key for good optimization of OO code with
many small methods), etc.   Currently, Soot does .class -> .class
optimization.  You would think that Sun's HotSpot would not get any gain
from such a static optimizer, but you would be wrong (as we have
unexpectedly discovered); statically optimized class files were faster
on many vms and many platforms (Linux,WinNT,...).  You can give a look
at the CC'2000 paper on the Sable web page
(http://www.sable.mcgill.ca/), under publications.

OK.  That was it for the commercial;-)  As you are programming the
thing, you get to decide whatever tools you will to use:-)))

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

Re: JIT optimization framework (was: Re: [Sablevm-user] bug report...)

[Andrew P. <apu...@ac...>]

"Etienne M. Gagnon" wrote:

> Have you looked at the "Soot" framework
> (http://www.sable.mcgill.ca/soot/)?  It does already provide more than
> this, including most analyses you need.  It's internal representation is
> "stackless" 3-address codes, with "typed" local variables.  We have
> already a few papers about this.  It might be a good starting point.
> Currently, Soot statically analyses whole applications with no dynamic
> class loading, but you could probably adapt it to dynamic code.

Thanks!

And now I guess I know where the name "SableVM" comes from...

> Assuming SableVM already executes the bytecodes (while you are
> optimizing them on another thread), this should have already been done,
> so you shouldn't care about verification in the JIT.

That's true. 

> As I said in an earlier message, I do not think that JIT compiling every
> method is a good way to go.  Ideally, you want the optimizer to pick
> frequently executed code, then take the time to crunch this as best as
> it can. 

I agree. It is the VM's choice when to invoke the JIT anyway. It is
free to compile information wrt. method invocation and invoke the JIT
only when a particular method meets some selection criteria -- such as
a high invocation count, code length, or advance knowledge of
performance "importance". It's an integration detail, albiet a big
one.


Andrew Purtell
from home -- apu...@ac...

Re: JIT optimization framework (was: Re: [Sablevm-user] bug report...)

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

Andrew Purtell wrote:
> I note that you generate assembly text and then compile it. I was
> thinking of doing something more along the lines of the following:
> 
>   - Partition bytecodes into basic blocks while building a control
>     flow graph.

Have you looked at the "Soot" framework
(http://www.sable.mcgill.ca/soot/)?  It does already provide more than
this, including most analyses you need.  It's internal representation is
"stackless" 3-address codes, with "typed" local variables.  We have
already a few papers about this.  It might be a good starting point. 
Currently, Soot statically analyses whole applications with no dynamic
class loading, but you could probably adapt it to dynamic code.

>   - Optionally run the standard Java code safety verification process,
>     if this has been requested, e.g. "jvm -verify ..."

Assuming SableVM already executes the bytecodes (while you are
optimizing them on another thread), this should have already been done,
so you shouldn't care about verification in the JIT.

>   - Convert bytecodes into register transfer lists, mapping values on
>     the operand stack to symbolic registers.
> 
>   - Hand off the RTL to "plug-in" optimization modules. What
>     optimizations are actually performed depend very much on how
>     quickly I can get them to operate. Some classic optimizations are
>     very time-intensive. Initially I was thinking:
> 
>       - Constant folding, constant propagation, copy propagation, and
>         value numbering.
> 
>       - Code straightening and jump threading.
> 
>       - Common subexpression elimination (maybe).
> 
>       - Dead code elimination (maybe).
> 
>       - Replacement of certain bytecode patterns with precooked
>         assembly templates, e.g. for x86:
> 
>             aload $value; invokevirtual "ntohl" ->
>                 asm ("bswap %0" : "=r" (value) : "0" (value))
> 
>             aload $value; invokevirtual "ntohs" ->
>                 asm ("xchgb %b0,%h0" : "=q" (value) :  "0" (value))
> 
>         or for Alpha:
> 
>             aload $value; invokevirtual "ntohs" ->
>                 asm ("insbl %2,1,%1; extbl %2,1,%0; or $2,$1,$2"
>                      : "=r"(t1), "=&r"(t2) : "r"(x))
> 

Some of these are probably better left to a higher 3-address
representation (see Soot).  Others might fit well with a back-end,
including some peep-hole optimizations.

>   - Finally, hand over the munged RTL to an emitter which emits native
>     code directly into space allocated on the Java heap. The emitter
>     would assign real registers from symbolic ones using one of the
>     graph coloring algorithms. If that kind of thing is too expensive,
>     there are alternatives.
> 
>   - For Alpha, a final peephole optimization pass is required because
>     instruction scheduling is very important for that platform.
> 
> All of that may be a bit much for a JIT, but whether or not that is
> true is what I want to find out. :)

As I said in an earlier message, I do not think that JIT compiling every
method is a good way to go.  Ideally, you want the optimizer to pick
frequently executed code, then take the time to crunch this as best as
it can.  The idea is, if the interpreter is fast enough, then this
should be OK, as short programs will execute fast enough, and long
running programs will benefit from an aggressive optimizer.


Etienne


> I would also want to add a module for converting variable references
> to immediate constants if the values are known at runtime. Perhaps
> there will also be an API for specifying such values. Code like this:
> 
>    if (case_a_is_true) {
>        /* a long block of code follows */
>    } else {
>        /* more code */
>    }
> 
> could be processed into:
> 
>    /* case_a_is_true is constant and always false */
>    /* more code */
> 
> Implementing all of the optimization framework in Java means
> everything is very dynamic and -- best of all -- can be self-
> bootstrapped into native code for maximum performance.
> 
> Andrew Purtell
> from home -- apu...@ac...
> 
> _______________________________________________
> Sablevm-user mailing list
> Sab...@li...
> http://lists.sourceforge.net/mailman/listinfo/sablevm-user

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

JIT optimization framework (was: Re: [Sablevm-user] bug report...)

[Andrew P. <apu...@ac...>]

> "John Leuner" <je...@pi...>  wrote:
> Andrew, I've been developing a JVM for the past while 
> (kissme.sourceforge.net), it's implemented in C and targeted at (free) 
> UNIX. 

Hi, John.

> Unfortunately I had to stop working on this project for two months
> due to a sports injury but I've recovered enough to carry on working 
> now. 

That's unfortunate. I'm sorry to hear that.

> If you're interested in the code or just discussing jits or
> whatever, just let me know. 

Both. :)

I've downloaded your 0.07 source and I'll have a look next week when I 
have time.

As for my interest in JIT technology, I've been inspired by the
OpenJIT project (www.openjit.org) to implement a JIT framework where
the JIT, code generator, and optimizer are all first-class Java
objects. Normally I am not taken to duplicating the work of others,
but this is cool technology that really should be available under the 
GPL. I have not looked at the OpenJIT source, so this will be a 
"clean-room" effort in the respect. I'm investigating if that status
also applies to work with Java in general.

I note that you generate assembly text and then compile it. I was
thinking of doing something more along the lines of the following:

  - Partition bytecodes into basic blocks while building a control
    flow graph.

  - Optionally run the standard Java code safety verification process, 
    if this has been requested, e.g. "jvm -verify ..."

  - Convert bytecodes into register transfer lists, mapping values on
    the operand stack to symbolic registers.

  - Hand off the RTL to "plug-in" optimization modules. What
    optimizations are actually performed depend very much on how 
    quickly I can get them to operate. Some classic optimizations are
    very time-intensive. Initially I was thinking:

      - Constant folding, constant propagation, copy propagation, and 
        value numbering.

      - Code straightening and jump threading.

      - Common subexpression elimination (maybe).

      - Dead code elimination (maybe).

      - Replacement of certain bytecode patterns with precooked 
        assembly templates, e.g. for x86:

            aload $value; invokevirtual "ntohl" ->
                asm ("bswap %0" : "=r" (value) : "0" (value))

            aload $value; invokevirtual "ntohs" ->
                asm ("xchgb %b0,%h0" : "=q" (value) :  "0" (value))

        or for Alpha:

            aload $value; invokevirtual "ntohs" ->
                asm ("insbl %2,1,%1; extbl %2,1,%0; or $2,$1,$2"
                     : "=r"(t1), "=&r"(t2) : "r"(x))

  - Finally, hand over the munged RTL to an emitter which emits native 
    code directly into space allocated on the Java heap. The emitter 
    would assign real registers from symbolic ones using one of the
    graph coloring algorithms. If that kind of thing is too expensive, 
    there are alternatives.

  - For Alpha, a final peephole optimization pass is required because
    instruction scheduling is very important for that platform.

All of that may be a bit much for a JIT, but whether or not that is
true is what I want to find out. :)

I would also want to add a module for converting variable references
to immediate constants if the values are known at runtime. Perhaps
there will also be an API for specifying such values. Code like this:

   if (case_a_is_true) {
       /* a long block of code follows */
   } else {
       /* more code */
   }

could be processed into:

   /* case_a_is_true is constant and always false */
   /* more code */

Implementing all of the optimization framework in Java means
everything is very dynamic and -- best of all -- can be self-
bootstrapped into native code for maximum performance.


Andrew Purtell
from home -- apu...@ac...

Re: [Sablevm-user] JIT integration (was RE: bug report -- cannot run 'HelloWorld' test)

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

"Purtell, Andrew" wrote:
> You mentioned that another individual has approached you about
> integrating a JIT with SableVM. The only work required on the SableVM
> side for supporting any JIT is the integration of a generic interface
> that
> 
> 1) allows the JIT a means for substituting native code for bytecodes,
> e.g. a simple protocol for letting the interpreter know native code has
> been generated from bytecode and a means for insuring that subsequent
> method invocations transfer control to that native code

That's already in place in SableVM (that's how native methods are
called).

> 2) extends the runtime with a few native methods for accessing internal
> state normally not exposed, such as the constant pool

Hmmm... Currently, I do not keep a copy of the original bytecodes
around;  you might need that.  This is also related to the problem of
accessing the constant pool.

SableVM "prepares" the bytecode before execution;  It replaces Java
bytecodes by its own bytecodes and it resolves constant pool references,
and it sometimes stores the result along the transformed bytecodes (like
LDC).

Two choices:
1- SableVM keeps a copy of the original class file bytes around (on a
class and/or method basis?).
2- Some interface is defined that extracts "standard" information from
SableVM's instruction mapping.  The interface would ideally not be tied
to SableVM's internals (improving the portability of the JIT;-).

I would suggest (2-), but you will have to understand SableVM's internal
structure (not that hard).

> Note that having a JIT implemented mostly in Java means that the JIT,
> generated code, and associated state are first-class Java objects.
> 
> There would certainly be the expectation that this would be my work, and
> at various milestones patches would be submitted for consideration. If
> SourceForge CVS can be accessed by another protocol than pserver, then I
> could instead check in the work under a branch. Unfortunately our
> firewall blocks pserver, though rsh and ssh are allowed.

If you have "clean-room" status, I can certainly add you as an official
developer and give you write access to the ssh/cvs repository (see the
developers page for precise information).

Mainly, you shouldn't have signed the Sun community license, or had
access to any Sun "confidential" intellectual property (related to
Java;-).

> I expect that JIT compiled code can adhere to the requirements of the
> runtime environment, whatever they are. Whether or not there are
> performance losses because of them depends on how clever the JIT
> implementor is. :)

OK.

> 
> > What's the protocol for passing arguments and results back
> > and forth?  (does it also require ffi?)
> 
> Presumably a JIT would use the same convention and glue that is in place
> for invoking native methods. There is nothing that ties it to a
> particular library or convention, so those can change as need be. I
> develop on both the x86 and Alpha platforms. If this effort were to take
> off, I would eventually like to see a SableVM/JIT combination running on
> both.

You could initially restrict JIT-code->SableVM communication to JNI. 
(e.g., if native code needs to access a field, it has to use
GetFieldID/Get<type>Field).  The JIT generated code would still have an
advantage over pure JNI code, and that to make things efficient, 
GetFieldID could be called by the JIT and Get<type>Field encoded in the
JIT-generated code, thus saving potentially a big number of calls to
GetFieldID (if running in an inner loop).

SableVM->JIT-code will require a specialized interface, unless you plan
to put the generated code into a *.so library and ask SableVM to
dynamically link and resolve symbols, as it does for native (JNI)
calls.  But, ideally, it would mimic JNI in the idea that it would get a
JNIEnv pointer, an instance/class pointer.  The only different thing
would be that it would then receive a pointer to the remaining arguments
and it would return a pointer to the result.  (Unlike JNI methods that
declare all their parameters, and return values directly).  One
advantage you get over JNI is that this call can now be a simple
indirect call through a normal function pointer (JNI requires the
complex encoding of ffi to push/pop arguments/result appropriately on
the C native stack).

Side question: You don't plan to JIT every method, do you?  I think that
this could potentially make SableVM slower.  Have you investigated
"selective" JIT compilation?  I think this is one part where John might
have a few ideas;-)

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

Re: [Sablevm-user] bug report -- cannot run 'HelloWorld' test

[John L. <je...@pi...>]

> There's also John Leuner <je...@pi...> who talked to me about
> porting his JIT to SableVM.  You might want to talk with him about
> that.  Maybe you two could help each other.

Hello Etienne, Andrew

Andrew, I've been developing a JVM for the past while
(kissme.sourceforge.net), it's implemented in C and targeted at (free)
UNIX. 

My current project is a JIT written in Java that doesn't conform to the
traditional SUN JIT spec. It comprises of an i386 Assembler written in
Java (although I wish I had a 64-bit architecture :-)) that is used to
translate bytecodes into machine code.

A typical excerpt from the code:

   case op.iconst_5:
            qc("mov eax,0x5 ; iconst_5");
            qc("push eax");
          break;
            /* Load instructions 

               These generally get the pointer to optop by calculating ebp
+ 0x8 and storing it in eax
               Then we add 0,4,8,12 to eax and push [eax]
             */

        case op.fload_0:
        case op.iload_0:
        case op.aload_0:
            qc("mov eax,[ebp + 0x8]");
            qc("push [eax]");
        break;


You can see I use an intel-style assembler syntax. I've basically
replaced the java stack with the native C stack, and all the translated
instructions operate on this native stack. Because of the nature of the
translation the resulting code could probably be optimised a lot. Future
work would be a second stage optimising version of this translator which
uses conventional optimisation techniques to produce faster code.

The translation gets more complicated when the VM wants to invoke a method
or put a value into an array etc, currently I handle these cases by having
the optimised code call back into a special C routine that does what is
necessary.

My next endeavor is to teach the "assembler" to understand some C structs
and thus have easy access to the fields of necessary structures. 

If that can be done the only real special-cases will be method-invocation. 


My JIT is selective, it only compiles certain methods and I intend to
insert some kind of profiling ability at a later stage. 

Unfortunately I had to stop working on this project for two months due to
a sports injury but I've recovered enough to carry on working now.

If you're interested in the code or just discussing jits or whatever, just
let me know.

John Leuner

[Sablevm-user] JIT integration (was RE: bug report -- cannot run 'HelloWorld' test)

[Purtell, A. <And...@NA...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> "Etienne M. Gagnon" wrote:

> You mean that the "re-implemented" version would be GPLed (+ JNI
> exception, like SableVM), right?

Yes.

> my requirement is that I do not have to change the structure
> of SableVM; the JIT has to adapt, and you get to do the work
> (I can help answering questions, though;-)

Yes, that is the idea.

> It's ok for additional per method data.  SableVM could even encode 
> JIT method calls using its own internal bytecodes (much like it
> does for native calls).

You mentioned that another individual has approached you about
integrating a JIT with SableVM. The only work required on the SableVM
side for supporting any JIT is the integration of a generic interface
that

1) allows the JIT a means for substituting native code for bytecodes,
e.g. a simple protocol for letting the interpreter know native code has
been generated from bytecode and a means for insuring that subsequent
method invocations transfer control to that native code

2) extends the runtime with a few native methods for accessing internal
state normally not exposed, such as the constant pool

Note that having a JIT implemented mostly in Java means that the JIT,
generated code, and associated state are first-class Java objects.

There would certainly be the expectation that this would be my work, and
at various milestones patches would be submitted for consideration. If
SourceForge CVS can be accessed by another protocol than pserver, then I
could instead check in the work under a branch. Unfortunately our
firewall blocks pserver, though rsh and ssh are allowed.

> [e.g. SableVM object instances can move in memory (copying 
> collection), so the JIT must cope with this]. 

> Will JIT compiled code use JNI local/global refs? (it should.  
> Even SableVM uses them internally)

I expect that JIT compiled code can adhere to the requirements of the
runtime environment, whatever they are. Whether or not there are
performance losses because of them depends on how clever the JIT
implementor is. :)

> What's the protocol for passing arguments and results back
> and forth?  (does it also require ffi?)

Presumably a JIT would use the same convention and glue that is in place
for invoking native methods. There is nothing that ties it to a
particular library or convention, so those can change as need be. I
develop on both the x86 and Alpha platforms. If this effort were to take
off, I would eventually like to see a SableVM/JIT combination running on
both.


Andrew Purtell
NAI Labs at Network Associates, Inc.
Los Angeles, CA
PGP Fingerprint: 5A21 10DB 92B0 CE20 80B4  90D7 A89C D464 AA0A A616

The difference between theory and practice in practice is larger 
than the difference between theory and practice in theory. -- Steve
Crocker


-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1
Comment: Crypto Provided by Network Associates <http://www.nai.com>

iQA/AwUBOYDp2aic1GSqCqYWEQLOLQCgh2R8Adu6NGI8HN5mp52UD1o5yPkAoKpK
vycB1Cpv9ZIEUL6qwHFzXeP8
=5Hsh
-----END PGP SIGNATURE-----

Re: [Sablevm-user] bug report -- cannot run 'HelloWorld' test

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

Hi Andrew,

"Purtell, Andrew" wrote:
>... OpenJIT itself is not GPLed, so this work would
> be a bottom-up reimplementation, anyway.

You mean that the "re-implemented" version would be GPLed (+ JNI
exception, like SableVM), right?

> About how far away from running HelloWorld is SableVM?

I would say a week (or two).  But, you never really know before you're
there...

> More importantly, is this something that fits into the design of SableVM?

It could.  I use SableVM for my Ph.D. research.  My goal is to get as
efficient a vm as possible without resorting to assembly language.

So, as far as my Ph.D. goes, a JIT is not a necessity.  But, I have no
objection to allow (optionally) a JIT to operate within SableVM, as long
as I do not have to compromise its data structure design. [e.g. SableVM
object instances can move in memory (copying collection), so the JIT
must cope with this].  Also, I won't have much time to work on the JIT
integration (at least, until I get my diploma;-)

> E.g. there would need to be a few hooks in the interpreter to support a
> JIT, especially a self-bootstrapping one. Just for purposes of example,
> this could be something as simple as:
> 
>     /* invoke method code */
>     (*obj->method->invoke)(args);
> 
> where normally 'invoke' points to 'int interpret_method (...)', but once
> a native method has been compiled, this pointer would be changed to 'int
> native_method (void * code, ...)'. Also, the JIT would need to store some
> per-method state, presumably hanging off a 'void * jit_priv' member in
> the appropriate struct. Etc.

You're talking about many things...  It's ok for additional per method
data.  SableVM could even encode JIT method calls using its own internal
bytecodes (much like it does for native calls).

The problem is: what's the protocol for vm<->JIT communication?  The vm
does precise stack scanning (for precise gc).  Will JIT compiled code
use JNI local/global refs? (it should.  Even SableVM uses them
internally)  What's the protocol for passing arguments and results back
and forth?  (does it also require ffi?)...  As I said, I think it is
feasible, but my requirement is that I do not have to change the
structure of SableVM; the JIT has to adapt, and you get to do the work
(I can help answering questions, though;-)

There's also John Leuner <je...@pi...> who talked to me about
porting his JIT to SableVM.  You might want to talk with him about
that.  Maybe you two could help each other.

Ideally, I should get Hello World working before we get into deep
discussions, because once it works, you will be able to explore the code
and get a better idea of SableVM's design.

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

RE: [Sablevm-user] bug report -- cannot run 'HelloWorld' test

[Purtell, A. <And...@NA...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Let me explain my interest in SableVM:

I have been looking at the OpenJIT project recently (see
http://www.openjit.org). Essentially, OpenJIT allows the majority of the
JIT to be implemented as Java classes, which lends itself to a number of
useful things such as runtime extension and specialization. The current
OpenJIT prototype runs on a modified Sun classic JVM. I'm looking to
"port" (read further) OpenJIT to an unencumbered JVM. Since SableVM is
GPLed, this is perfect. OpenJIT itself is not GPLed, so this work would
be a bottom-up reimplementation, anyway.

About how far away from running HelloWorld is SableVM?

More importantly, is this something that fits into the design of SableVM?
E.g. there would need to be a few hooks in the interpreter to support a
JIT, especially a self-bootstrapping one. Just for purposes of example,
this could be something as simple as:

    /* invoke method code */
    (*obj->method->invoke)(args);

where normally 'invoke' points to 'int interpret_method (...)', but once
a native method has been compiled, this pointer would be changed to 'int
native_method (void * code, ...)'. Also, the JIT would need to store some
per-method state, presumably hanging off a 'void * jit_priv' member in
the appropriate struct. Etc.


Andrew Purtell
NAI Labs at Network Associates, Inc.
Los Angeles, CA
PGP Fingerprint: 5A21 10DB 92B0 CE20 80B4  90D7 A89C D464 AA0A A616

The difference between theory and practice in practice is larger 
than the difference between theory and practice in theory. -- Steve
Crocker

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1
Comment: Crypto Provided by Network Associates <http://www.nai.com>

iQA/AwUBOYDUi6ic1GSqCqYWEQJ7bgCeN6JlKekXyIroeQ2K/NFkjpz73coAoJFM
DAsCBcBz1SsN9QOJB8rnfdfJ
=cM+V
-----END PGP SIGNATURE-----

Re: [Sablevm-user] bug report -- cannot run 'HelloWorld' test

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

Just to make sure I express myself correctly:

Dynamic lookup of symbols is implemented.  This is why a call to a
dynamically discovered function like Java_java_lang_VMSystem_arraycopy
works.

But, SableVM has also to be able to find libraries (*.so) dynamically,
which it yet doesn't do.

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

Re: [Sablevm-user] bug report -- cannot run 'HelloWorld' test

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

Hi Andrew,

"Purtell, Andrew" wrote:
> I downloaded SableVM and Sablepath, and attempted to run the 'HelloWorld'
> test as shown on the project home page:
>... 
> executing java/lang/Runtime getLibraryPath ()Ljava/lang/String;
> native: Java_java_lang_Runtime_getLibraryPath
> executing java/lang/Runtime <init> ()V
> 
> Program received signal SIGSEGV, Segmentation fault

This Segmentation fault is expected.

Extracted from the "NEWS" file:
-----
* version 0.1.4

Removed -Werror compiler option from distribution.
As before, it only runs until a native call to
Java_java_lang_Runtime_getLibraryPath().
-----

What is happening is that SableVM doesn't succeed at resolving the
symbol "Java_java_lang_Runtime_getLibraryPath" in a dynamically linked
library.  As the lookup procedure for linking dynamic libraries is not
fully implemented, I didn't want to spend time (yet) making SableVM fail
gracefully on failure to lookup a symbol.

I am currently working on this, as I want to be able to test SablePath's
native code, which requires library dynamic lookup.

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

[Sablevm-user] bug report -- cannot run 'HelloWorld' test

[Purtell, A. <And...@NA...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I downloaded SableVM and Sablepath, and attempted to run the 'HelloWorld'
test as shown on the project home page:

Running on RedHat 6.2 (Glibc 2.1, Kernel 2.2.16)

versions:

	SableVM		0.1.4
	Sablepath		0.1.1
	Glibc			2.1
	libffi		1.20
	popt			1.5
	libgmp		3.0.1

SableVM version 0.1.4
...
creating HelloWorld
creating java/lang/Object
...
Hello from native!
...
executing java/lang/String arraycopy
   Ljava/lang/Object;ILjava/lang/Object;II)V
executing java/lang/String <init> ([C)V
executing java/lang/System loadLibrary (Ljava/lang/String;)V
creating java/lang/Runtime
java/lang/Runtime created
executing java/lang/Runtime <clinit> ()V
executing java/lang/Runtime <init> ()V
creating [Ljava/lang/String;
[Ljava/lang/String; created
executing java/lang/Object <init> ()V
executing java/lang/Runtime <init> ()V
executing java/lang/Runtime getLibraryPath ()Ljava/lang/String;
native: Java_java_lang_Runtime_getLibraryPath
executing java/lang/Runtime <init> ()V

Program received signal SIGSEGV, Segmentation fault
_svmf_interpreter (env=0x40164104) at interpreter.c:1913
1912	_svmf_object_instance *obj = stack[frame->stack_size - params].addr;
1913	_svmt_method_info *method = 
1914	  ((_svmt_method_info **) obj->vtable)[vtable_offset];

(gdb) p obj
$1 = (_svmt_object_instance *) 0x16b23ab4   <--- bogus address

(gdb) p *frame
$2 = {previous_offset = 50, end_offset=51, method=0x405c733e,
  pc = 0x405c8638, stack_size = 1}

(gdb) p params
$3 = 1

(gdb) p stack[0]
$4 = {jint = 380779199}, jfloat = 2.8794525e-25, addr=0x16b23abf}

Not sure how much help this is... If anyone wants further information,
let me know.


Andrew Purtell
NAI Labs at Network Associates, Inc.
Los Angeles, CA
PGP Fingerprint: 5A21 10DB 92B0 CE20 80B4  90D7 A89C D464 AA0A A616

The difference between theory and practice in practice is larger 
than the difference between theory and practice in theory. -- Steve
Crocker

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1
Comment: Crypto Provided by Network Associates <http://www.nai.com>

iQA/AwUBOYCFDqic1GSqCqYWEQLaBACgr7Csv1LYl+SUP1+ovTg4P3kDa34An3Dv
Q7Vf+Mo96dAFxtPLIHkAv3ef
=pTZO
-----END PGP SIGNATURE-----

Re: [Sablevm-user] About closures...

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

Brent Fulgham wrote:
> These sound like excellent ideas.  The only other thing that might be
> useful would be a "UseSameFrame" bytecode for help with tail-recursive
> situations.  I.e., a Scheme compiler for SableVM would be able to provide
> the JVM with the "UseSameFrame" for a tail-recursive functions to
> save stack space and convert the 'recursive' function into an interation.


You know, this "UseSameFrame" bytecode would be almost trivial to
implement.  But more importantly, it would be very easy to extend the
verifier to check that it is correctly used:
 1 - The return type of the called method must be the same as the return
type of the currently executing method.  (You could probably accept
"stricter" types too, but I don't know if this is needed).
 2 - The current code shouldn't be enclosed in an exception handler.
This can be verified statically (meaning in the context of the vm: at
link time), which is great.  There would be some gymnsastics to move the
call parameters down (or up, depending on you point of view;-) the stack
to the appropriate slots, and extend/shrink the current frame
appropriately.

Of course, this "UseSameFrame" wouldn't be available to native methods. 
Or, to be precise:
 - A bytecode method IS ALLOWED to invoke native methods through the
"UseSameFrame" bytecode.
 - A native methods CANNOT is limited to the current JNI interface,
which desn't export a similar functionality.

This would be a good thing, as:
 - The native code uses the normal "C" stack, which is (or can be)
different from the interpreter stack.  The native language can already
have its own mechanisms to "reuse" the current stack frame, so exporting
the functionality from the VM is not that important.
 - The VM stack contains frame(s) of "Local" references, which handling
would become a nightmare if the "UseSameFrame" functionality was
exported.


Etienne
PS: You may use these ideas as you see fit, but I would be grateful that
you gave me credit.
PPS: It might be interesting, at some point, and if our projects go
along, to write some joint paper(s);-)
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableVM:                             http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-user] About closures...

[Brent F. <bfu...@de...>]

On Mon, Jul 17, 2000 at 05:52:27PM -0400, Etienne M. Gagnon wrote:
> Hi Brent.
> 
> If memory serves me right, in fact what you want is to be able to "save"
> a snapshot of the stack, then, at a later time, be able to resume
> computation starting with this snapshot.
> 
I think that is termed a 'continuation', which in Scheme you would
signal starting as 'letcc'.  This is one critical piece of the system.
Closure refers to variables being bound inside function definitions,
such, e.g.:

(define test
    (lambda (a)
        (lambda (b)
	    (+ a b))))

(define foo1 (test 10))	
(define foo2 (test 20))

Now if we do:

>(foo1 20)
30
>(foo2 20)
40

We say 'foo1 has closure on "a"' because it remembers that
it's internal a=10, while foo2 has an internal a=20.  I think this
is relatively easy to simulate in a JVM (Kawa does it with inner
classes I believe).  The problem is that because the JVM memory
management is so bad, it's very costly when compared to a dedicated
Scheme bytecode interpreter.

The harder part is the 'continuation' concept, which you describe
further below.

> Do you really need to open the access to the internal VM representation
> to implement this?  I mean:  would simply providing two new bytecodes,
> say NewClosure/UseClosure, be enough?  As I said before, I am not very
> knowledgeable about FP runtime systems. e.g. I do not know tha answer to
> questions like: Does the closure only include the current thread's
> stack, or does it need a full copy of the overall VM state?  How do you
> resume a closure: on a new thread? If not, what happens with the current
> stack? etc.

I think this sounds like a great idea.
> 
> I think that, in general,  providing new bytecodes, for extended
> functionality, is better than opening up the internal state, in that it
> helps shielding away applications from any specific VM implementation.
> 
> Just some thoughts;-)

These sound like excellent ideas.  The only other thing that might be
useful would be a "UseSameFrame" bytecode for help with tail-recursive
situations.  I.e., a Scheme compiler for SableVM would be able to provide
the JVM with the "UseSameFrame" for a tail-recursive functions to
save stack space and convert the 'recursive' function into an interation.

Great ideas!

-Brent

[Sablevm-user] About closures...

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

Hi Brent.

If memory serves me right, in fact what you want is to be able to "save"
a snapshot of the stack, then, at a later time, be able to resume
computation starting with this snapshot.

Do you really need to open the access to the internal VM representation
to implement this?  I mean:  would simply providing two new bytecodes,
say NewClosure/UseClosure, be enough?  As I said before, I am not very
knowledgeable about FP runtime systems. e.g. I do not know tha answer to
questions like: Does the closure only include the current thread's
stack, or does it need a full copy of the overall VM state?  How do you
resume a closure: on a new thread? If not, what happens with the current
stack? etc.

I think that, in general,  providing new bytecodes, for extended
functionality, is better than opening up the internal state, in that it
helps shielding away applications from any specific VM implementation.

Just some thoughts;-)

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

FW: [Sablevm-user] Greetings!

[Brent F. <bre...@xp...>]

Attached are some messages related to problems that certain JVM-targetted 
projects have had with the currently available JVM's:

1.  The Kawa (Scheme in Java) system has performance problems because
Continuations are not supported at the JVM level:
http://sources.redhat.com/ml/kawa/1999/msg00006.html

2.  Note to Comp.Compilers about possible exporting of internal
JVM constructs for use in continuations:
http://compilers.iecc.com/comparch/article/97-01-256

3.  This homework assignment refers to some instructor-created JVM code
that apparently helps support continuations (note:  haven't actually
read this code)
http://www.eecs.harvard.edu/~nr/cs152/homework/sem.html

At any rate, it seems that a neat niche that SableVM might exploit
would be as a Java-compliant JVM that could also export access to its
internal state for use in implementing closures/continuations.  I'm going
to e-mail Per Bothner (the Kawa creator) to see his thoughts on how this
might be accomplished.

Thanks,

-Brent

[Sablevm-user] Announcement: Libffi Debs

[Brent F. <bfu...@de...>]

For any SableVM hackers running Debian systems, your build might
have failed because the "ffi.h" header file was missing.  In
fact, Debian did not have a "libffi" package at all (which is a
problem since SableVM relies on it).

I have generated a libffi 'deb' file, which can be downloaded
from:

http://www.debian.org/~bfulgham/libffi_1.20-1_i386.deb

I have also uploaded to the Incoming directory for Debian (master).
It will take a week or so to be incorporated into the main
archive, added to the Packages.gz file, etc.  Once that happens,
it will be fully under control of 'dpkg/dselect/apt'.

Have fun, and let me know if you have any problems with it.

Thanks,

-Brent

Re: [Sablevm-user] Greetings!

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

Hi Brent.

> To my knowledge, I have *NOT* ever agreed to the SUN community
> source license.  I have also never seen any source code for the
> SUN base classes.

Terrific!

> Yes, I am a Debian developer, so I will be more than happy to
> produce binaries for the Debian system whenever you feel that
> Sable is in good shape.

That would be really great!

> I will download the source code and try a quick compile to see
> how things go!  :-)

Tell me if you have any problem, so that we make it as easy as possible
for people to compile the thing.

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

Re: [Sablevm-user] Greetings!

[Brent F. <bfu...@de...>]

Etienne,

To my knowledge, I have *NOT* ever agreed to the SUN community
source license.  I have also never seen any source code for the
SUN base classes.

I have downloaded the SUN Java tools, but I don't believe this
requires agreement with the SUN community source license.  I know
I have also downloaded documents and some proposed specifications
from their site, but I do not believe any of these required any
special agreements.

I know that I have never physically signed any documents (including
NDA, non-compete, etc.) or done any work with them.  I have never
received source code from SUN or others related to the SUN tools.

I have been conscious of the licensing issue since I played with
Japhar/Classpath and did not want to taint anything.

Yes, I am a Debian developer, so I will be more than happy to 
produce binaries for the Debian system whenever you feel that
Sable is in good shape.

I will download the source code and try a quick compile to see
how things go!  :-)

-Brent



> -- 
> ----------------------------------------------------------------------
> Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
> Author of SableVM:                             http://www.sablevm.org/
> ----------------------------------------------------------------------
> 
> 
> _______________________________________________
> Sablevm-user mailing list
> Sab...@li...
> http://lists.sourceforge.net/mailman/listinfo/sablevm-user

Re: [Sablevm-user] Greetings!

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

Hi Brent.

"Etienne M. Gagnon" wrote:
> In fact, you can simply export CFLAG='-Werror -O0 -ggdb' then try to

Obviously, what I really meant was CFLAGS (with an S).

I noticed you have a "debian" address, so I guess you might know a
little about *.deb packages.  Building Debian source/binary packages
would be useful, too;-)

Feel free to pick whatever help area you are interested in.  If you
discover anything you think you'd like to do, just suggest it.

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