sablevm-developer

[Sablevm-developer] Re: Compile issue

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

Hi Brent,

I am continuing this thread on the SableVM-Developer list.

Brent Fulgham wrote:
> I've attached a diff for your review.  I wouldn't dare apply this to
> the archive until you look at it.  It's probably pretty inefficient --
> I think with some thought we could probably get rid of some copying.

I think you actually forgot to attach the diff (it happens to me often
too, to forget attachments;-).

> At any rate, my idea was to allow --boot-class-path to accept things
> of the form:
> 
> --boot-class-path=/usr/lib/sablepath/classes:.
> 
> (just like regular ":"-delimited path lists).
> 
> To get this to work, I had to make a few changes, but I think the
> scope of the modifications is relatively small.

If we implement this for --boot-class-path, we must also implement it
for --boot-library-path.  We should also take care of adding a trailing
"/" when necessary, e.g.:

(All of these should be valid)

 --boot-class-path=/usr/lib/sablepath/classes/:./  
 --boot-class-path=/usr/lib/sablepath/classes:./  
 --boot-class-path=/usr/lib/sablepath/classes/:.  
 --boot-class-path=/usr/lib/sablepath/classes:.  

If we want to accept "relative" paths (like "."), we should first
convert them into absolute paths.  I do really dislike the JDK's
vulnerability in this regard (as using a file dialog can change the
current work directory and cause all sorts of problems).

I don't know if it is a good thing, or not, to accept all of these
things in the boot class path (see discussion below).  It might be
sufficient to simply accept a single absolute path.

> One thing I'm not sure of is if "class-path" should be the path
> to the main class archive, the classes I intend to run, or some
> combination.  And how about --boot-class-path?  It seems that the
> class you pass on the command-line must be in the --boot-class-path
> path as well.
> 
> Why do we need two class-paths?

OK.  Let me start by saying that the current implementation of sablevm.c
is wrong.  It shouldn't instantiate the HelloWorld class.  It should,
instead, instantiate a special application class which will use a class
loader to load the HelloWorld class.

By using a class loader, it can retrieve this class from within a .jar
file, or any other location.  The code to do so will be written in Java
(relief for the vm writer;-).

The idea of having 2 kinds of class path is that:
boot-class-path:  This is the path to the standard libraries.
class-path:  This is the path to the user's classes.

Now, it might be interesting, eventually, to allow some boot classes to
be packaged into .jar files, but as I do not want to write .jar reading
code in C, some base classes have to be available directly on the file
system.  If we want to use both, we have to play a few tricks in the vm
to record specially that all these classes are in the same "runtime
package".  So, I would delay the implementation of this to later, when
we know that the normal class-path does implement runtime packages
correctly.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-developer] Re: Compile issue

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

On Sun, Dec 03, 2000 at 10:27:05AM -0500, Etienne M. Gagnon wrote:
> Hi Brent,
> 
> I am continuing this thread on the SableVM-Developer list.
> 
> Brent Fulgham wrote:
> > I've attached a diff for your review.  I wouldn't dare apply this to
> > the archive until you look at it.  It's probably pretty inefficient --
> > I think with some thought we could probably get rid of some copying.
> 
> I think you actually forgot to attach the diff (it happens to me often
> too, to forget attachments;-).
> 

Ack!  So I have.  Attaching now.

> If we implement this for --boot-class-path, we must also implement it
> for --boot-library-path.  We should also take care of adding a trailing
> "/" when necessary, e.g.:
> 
> (All of these should be valid)
> 
>  --boot-class-path=/usr/lib/sablepath/classes/:./  
>  --boot-class-path=/usr/lib/sablepath/classes:./  
>  --boot-class-path=/usr/lib/sablepath/classes/:.  
>  --boot-class-path=/usr/lib/sablepath/classes:.  
> 

Right -- I don't think this patch handles all such cases properly,
since it adds an extra '/' to the patch.  This is, of course,
easy to fix.  Although in practice I think the use of 
"[...]sablepath/classes//" just happens to work on most systems.

> If we want to accept "relative" paths (like "."), we should first
> convert them into absolute paths.  I do really dislike the JDK's
> vulnerability in this regard (as using a file dialog can change the
> current work directory and cause all sorts of problems).
> 
Okay.

> I don't know if it is a good thing, or not, to accept all of these
> things in the boot class path (see discussion below).  It might be
> sufficient to simply accept a single absolute path.
> 
Right -- with compile-time option so we don't always have to
pass it as a boot parameter.  Then --class-path would direct the
loader to our standard set of paths for classes.

(snipping rest of discussion, since I have nothing to add)

Thanks,

-Brent

Re: [Sablevm-developer] Re: Compile issue

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

Hi Brent.

Brent Fulgham wrote:
> Ack!  So I have.  Attaching now.

The patch looks OK.  (It's definitely not what I would keep in the final
optimized version of SableVM, but it looks operational).

Now, we have the choice of either using it, or fixing --class-path using
an application class loader (which is the right way to implement the
whole thing).

Would you like to work on the application class loader?

I would still consider your patch, in the short term, as it can be
convenient for testing.

What do you think?

> Right -- I don't think this patch handles all such cases properly,
> since it adds an extra '/' to the patch.  This is, of course,
> easy to fix.  Although in practice I think the use of
> "[...]sablepath/classes//" just happens to work on most systems.

In fact, if we really want to be system independent, we need to use
system properties for this.  All this is best done in Java, using an
application class loader.

> Right -- with compile-time option so we don't always have to
> pass it as a boot parameter.  Then --class-path would direct the
> loader to our standard set of paths for classes.

Hmmmm, why not in "/etc" (this path would be a compile time constant, as
I already do with the license files).  I would very much like sablevm to
use configuration files, instead of environment variables, to find its
default boot paths.  Much cleaner.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-developer] Re: Compile issue

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

On Sun, Dec 03, 2000 at 04:23:56PM -0500, Etienne M. Gagnon wrote:
> Hi Brent.
> 
> Brent Fulgham wrote:
> > Ack!  So I have.  Attaching now.
> 
> The patch looks OK.  (It's definitely not what I would keep in the final
> optimized version of SableVM, but it looks operational).
> 
> Now, we have the choice of either using it, or fixing --class-path using
> an application class loader (which is the right way to implement the
> whole thing).
> 

I think we should probably just leave the patch out of sablevm and move
directly to the class-loader.  The reason I say this is that unless we
want the ability to have multiple possible paths to the "base-classes"
and "base-libraries", there's not need for the performance hit of all
that copying and string manipulation.

> Would you like to work on the application class loader?
> 
Yes!  Can you point me towards any references on how it should work?
For example, I could possibly look at Kaffe's or Japhar's implementation
for hints since their licenses are GPL/LGPL.  Or are we approaching it in a
different fashion?  I don't know much about the innards of Kaffe.

> I would still consider your patch, in the short term, as it can be
> convenient for testing.
> 
> What do you think?
>
As I mentioned, it might be better to leave it out since it will encourage
me to actually implement the class loader ;-)  For now, it is convenient
enough for testing to just put the classes into base-class-path.

> > Right -- I don't think this patch handles all such cases properly,
> > since it adds an extra '/' to the patch.  This is, of course,
> > easy to fix.  Although in practice I think the use of
> > "[...]sablepath/classes//" just happens to work on most systems.
> 
> In fact, if we really want to be system independent, we need to use
> system properties for this.  All this is best done in Java, using an
> application class loader.
>

Sounds good to me.  Is it a goal to have SableVM compile under, for
example, Windows using Borland or Microsoft's compiler?  The VM code
looks like it makes use of some GNU C extensions.

> > Right -- with compile-time option so we don't always have to
> > pass it as a boot parameter.  Then --class-path would direct the
> > loader to our standard set of paths for classes.
> 
> Hmmmm, why not in "/etc" (this path would be a compile time constant, as
> I already do with the license files).  I would very much like sablevm to
> use configuration files, instead of environment variables, to find its
> default boot paths.  Much cleaner.
> 

Yes.  And easy to do.  We would want to retain the command-line parsing
to allow user-override.  So we just add some code to parse a simple
configuration file of "tag = value" pairs:

boot-class-path = /usr/lib/sablepath/classes
boot-library-path = /usr/lib/sablepath
class-path = /usr/share/java

What do you think?  I could code this up relatively quickly.  But
the class-loader will take more time while I research how it should
work.

-Brent

Re: [Sablevm-developer] Re: Compile issue

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

Brent Fulgham wrote:
> > Would you like to work on the application class loader?
> >
> Yes!  Can you point me towards any references on how it should work?
> For example, I could possibly look at Kaffe's or Japhar's implementation
> for hints since their licenses are GPL/LGPL.  Or are we approaching it in a
> different fashion?  I don't know much about the innards of Kaffe.

I do not know how they do it; but I know how I'd like it done;-)

See below.

> 
> Sounds good to me.  Is it a goal to have SableVM compile under, for
> example, Windows using Borland or Microsoft's compiler?  The VM code
> looks like it makes use of some GNU C extensions.

SableVM has the following "hard" dependencies:
1- ANSI C compiler & library
2- POSIX library

The current dependency on GNU C's labels as values will be optional,
hopefully selected automagically through some configure magic.  Did you
receive my request mail, on the SableVM-"USER" mailing-list?
(http://www.geocrawler.com/archives/3/4430/2000/11/0/4750188/)


> > Hmmmm, why not in "/etc" (this path would be a compile time constant, as
> > I already do with the license files).  I would very much like sablevm to
> > use configuration files, instead of environment variables, to find its
> > default boot paths.  Much cleaner.
> 
> Yes.  And easy to do.  We would want to retain the command-line parsing
> to allow user-override.  So we just add some code to parse a simple
> configuration file of "tag = value" pairs:
> 
> boot-class-path = /usr/lib/sablepath/classes
> boot-library-path = /usr/lib/sablepath
> class-path = /usr/share/java
> 
> What do you think?  I could code this up relatively quickly.  But
> the class-loader will take more time while I research how it should
> work.

I think there already exist some libraries for parsing such
configuration files.  Let me check the Debian archive for some license
compatible one (something like LGPL or public domain).

As for the class loader stuff, you will probably need to work in close
collaboration with me on this one, as it involves the VM.

How about fixing the parsing stuff first?  ;-)

I'll tell you as soon as (or if) I find a library.

Etienne
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-developer] Re: Compile issue

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

"Etienne M. Gagnon" wrote:
> SableVM has the following "hard" dependencies:
> 1- ANSI C compiler & library
> 2- POSIX library

In fact, there are some pretty fancy (and I would say: ugly) other small
system specific dependencies, like memory consistency models (i.e. how
the caches behave on multi-processor systems), alignment rules (some
systems require special allignment for long/doubles, I have learned
lately on the SableVM user mailing list), and atomic compare-and-swap
operation (which must be written as inlined assembly).

I hate having to deal with some of these issues, but they are essential
for a conforming vm. (#!@(*&%^@!#$*@#%!!!)
-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------

Re: [Sablevm-developer] Re: Config File Parsing

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

Have a look at "dot.conf", http://www.azzit.de/dotconf.  I think
it might do what we need.  It's also LGPL'd.

It doesn't appear to be packaged for Debian yet, so I'll take care
of that (after checking with others to see if it's in the works.)

-Brent

Re: [Sablevm-developer] Re: Config File Parsing

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

I forgot something: I am already using popt.  I now remember that it can
parse arbitrary strings in argv[] style arrays.

A very simple program could read options from a configuration file,
strip leading/trailing space characters (at the line beginning/end, and
around the first "=" character) then add a "--" prefix, then store the
result in an array of strings, then simply add to this array the strings
of argv[].  As usual, empty lines (after stripping) and comment lines
(starting with #) would be ignored.  Line continuation support would be
nice to have, too;-)

i.e.:

file content
------------
# comment
  boot-class-path = /usr/share/sablepath/classes
  boot-library-path \
    = /usr/share/sablepath/lib
...

converted into:

"--boot-class-path=/usr/share/sablepath/classes"
"--boot-library-path=/usr/share/sablepath/lib"


The nice thing, with this approach, is that we would automatically get
popt's error messages for invalid options (and optinally option
aliasing, too!)

This would probably be the best solution, as it fits nicely with the
current command line parsing code.

Etienne

Brent Fulgham wrote:
> 
> Have a look at "dot.conf", http://www.azzit.de/dotconf.  I think
> it might do what we need.  It's also LGPL'd.
> 
> It doesn't appear to be packaged for Debian yet, so I'll take care
> of that (after checking with others to see if it's in the works.)
> 
> -Brent
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> http://lists.sourceforge.net/mailman/listinfo/sablevm-developer

-- 
----------------------------------------------------------------------
Etienne M. Gagnon, M.Sc.                     e-mail: eg...@j-...
Author of SableCC:                 http://www.sable.mcgill.ca/sablecc/
and SableVM:                                   http://www.sablevm.org/
----------------------------------------------------------------------