sablevm-developer — SableVM developer mailing list

[Sablevm-developer] CODING file

[Chris P. <chr...@ma...>]

Here is a very short coding standards file.  I don't know where in 
sablevm/src you want to put it.  You might want to change the name, you 
might want it as part of the README.  It's up to you :)

Cheers,
Chris

Re: [Sablevm-developer] README for libsablevm

[Chris P. <chr...@ma...>]

Here is the corrected file with those two changes.  Note that at some 
point, somebody (probably you Etienne) needs to fix up my explanations 
because some of them I am not clear about.  However, if you just want 
something to commit now, it will be OK.

I tried to indicate all cases in the file where I was confused either 
about the existence of a file altogether, whether a file was too small 
and should be merged, or what the function of a file was.

To summarize:

1) it seems that everything in macros.c should go in cast.list, except 
for _svmf_is_same_object which should go in one of the util files.  I'm 
not sure if macros.c is obsolete or not.  It seems that macros.h is 
probably obsolete as well, and if not, should probably be targeted for 
replacement with m4 macros in the future.

2) all constants defined should go into constants.h and this should be a 
policy for anyone modifying the source.  i'm not sure if there are 
constants defined elsewhere in the VM.

3) I don't know why we need direct_threaded.m4, inlined_threaded.m4, 
switch_threaded.m4,
instructions_preparation.m4, and instructions_switch.m4.  In general, I 
think the very short files  like these are unnecessary.

4)
error_bits.m4.h:
error_classes.m4.h:
error_init_methods.m4.h:
error_instances.m4.h:
        very short multicallable macros to declare error types.
        not sure why all four of these files exist ... they are
        very similar and all declare macros of the same name.

5) gc_generational.c -- should be moved into libsablevm/dev or something 
until it is working.

6) class_file_parser.h .... don't really think we need this to be a 
separate file.  is it obsolete?

7) I need a better explanation for global_refs.* and local_refs.*

8) heap_manager.c: at least part or all of this file is obsolete i think 
(definitely the end)

9) heap_manager.h .... don't need an essentially empty header

10) I don't know why instructions_switch.m4.c exists, it seems similar 
to the content in instructions_preparation.m4.c and there are no files 
called instructions_inlined.m4.c, or instructions_direct.m4.c. 

11) move the java_lang_* stuff into libsablevm/java and remove vmlib.* 
altogether.

12)
jnidefs.h:
        definitions of jobject, jarray, jfieldID, and jmethodID.  why do
        these get their own special file, instead of being included in
        types.h or jni.h?

13) not sure what lib_init.c does

14) unclear about "specific" methods in method_invoke.list

15) do you need native_interface.h?

16) all type declarations should go in types.h .... this should be a 
policy like for constants.h  ... the stuff in system.h obviously 
shouldn't be in there though.  % grep typedef * shows that only 
pthread_rec_svm.* violates this.

17) util.h, util.m4.c., util1.c, and util2.c need to be cleaned up (see 
my comments in the file).  split
the util functions into two categories: those for working with the C 
language, and those for
working with Java data structures.  furthermore, util.h could be built 
from an m4 file and a list file it
seems.

18) all #include directives should go in libsablevm.c

====================

Finally, I think a TODO file in this directory would be useful, and 
moreover I think a TODO file in *each* directory could initially be 
built automatically using grep or some other tool, because in several 
comments in the code you've specified the word TODO (capitalization 
varies).   In general, I think putting "TODO:" in comments is a good way 
of maintaining a TODO file, except for things you really haven't coded 
at all (hence you need two sections in the file).  This is probably the 
kind of thing you could start using javadoc or doxygen for also -- but 
there's overhead in getting those things going and they don't solve the 
problem of existing TODO comments.

Also perhaps a CODING file that explains coding standards you've used 
throughout the VM (or whatever you want to call it) that could go in 
/sablevm/src or something.  I'm sometimes
confused about svmf, svmm, and svmt.

You wrote some helpful comments to me about the use of m4 last week, and 
sometime I'll add to the existing comments in macros.m4

I realize it is too much work to go back and document all the source all 
at once now, but we could come up with some documentation and coding 
standards for *future* changes to sablevm.  I really think we should 
consider using javadoc and/or doxygen (doxygen being more powerful and 
recognizing all javadoc syntax).  Apparently the tool "docbook" is also 
useful, but I think that's more high level.  Any document describing the 
actual code (not including theses and papers) that isn't at least 
partially built directly from the sources will be difficult to maintain 
and become obsolete quickly.  This README file isn't a problem because 
obviously one day we could move the descriptions to the top of files 
inside javadoc comments and then build the README automatically.

A final comment is that if anybody makes any changes to the source, they 
should *definitely* make sure they update corresponding comments ... an 
incorrect comment is worse than no comment at all.  I think you're 
probably not guilty of this, but as people start to contribute, it could 
get messy.  We need a separate thread about coding standards / 
documentation I think.

Cheers,
Chris

P.S.  I do think the organization / architecture of SableVM is very 
clean in general, so the process of fixing things shouldn't be too 
painful.  I've seen projects that are much worse.  But we do need to be 
proactive.

Prof. Etienne M. Gagnon wrote:

>Hi Chris,
>
>Thanks a lot for your text.  Could you:
>
>1- Send the finale corrected file.
>
>2- Tell me what files you would think should be merged, and why?  I
>used to personally think that some files were too long already... ;-)
>
>I know that a document describing SableVM's architecture is missing
>(and badly needed).  The problem is I currently don't have the time to
>write it.  I have some garbled hand written notes.  I *did* spend a
>lot of time designing SableVM's architecture *before* writing the code
>[I think it shows when you read the code], but I didn't write a
>structured document for it because of lack of time, my goal being to
>finish my Ph.D. as fast as possible.
>
>Etienne
>
>
>
>  
>

Re: [Sablevm-developer] README for libsablevm

[Prof. E. M. G. <eti...@uq...>]

Hi Chris,

Thanks a lot for your text.  Could you:

1- Send the finale corrected file.

2- Tell me what files you would think should be merged, and why?  I
used to personally think that some files were too long already... ;-)

I know that a document describing SableVM's architecture is missing
(and badly needed).  The problem is I currently don't have the time to
write it.  I have some garbled hand written notes.  I *did* spend a
lot of time designing SableVM's architecture *before* writing the code
[I think it shows when you read the code], but I didn't write a
structured document for it because of lack of time, my goal being to
finish my Ph.D. as fast as possible.

Etienne



--=20
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] README for libsablevm

[Chris P. <chr...@ma...>]

One last correction:

The following:

prepare_code.c:
prepare_code.h:
        implementation of recursive locks on top of pthread

should be replaced with:

prepare_code.c:
prepare_code.h:
        prepare method bodies (see Ch.2 of thesis)

pthread_rec_svm.c:
pthread_rec_svm.h:
        implementation of recursive locks on top of pthread

..........

Aside ... I just used this README file to figure out a list of files I 
need to look at when working on my current project and it was very helpful.

Chris Pickett wrote:

> Sorry ... the buffer.m4.c and buffer.m4.h files shouldn't be in the 
> README ... that's stuff I'm working on and I forgot to take it out.
>
> Cheers,
> Chris
>
> Chris Pickett wrote:
>
>> Hi,
>>
>> I looked through all files in libsablevm this morning and took 
>> notes.  The result is a README file in my local CVS.  It would be 
>> nice if this could be cleaned up and then committed to the main 
>> repository ... it can overwhelming when starting to look at the VM, 
>> and it's good to have a reference.  Perhaps some tips as to where to 
>> get started (e.g. looking at types.h and jni.h, reading the JNI / JVM 
>> specs) would also be helpful.
>> Although I couldn't give good descriptions for everything, this is 
>> better than nothing at all IMHO.  It would also be nice if currently 
>> unused files (e.g. gc_generational.c) were moved into a directory 
>> called dev, or just removed from the CVS if they're obsolete.  Also, 
>> it would be nice to combine some of the very small files into larger 
>> files.  Finally, perhaps the java_* stuff should be moved to a 
>> separate folder.  Just some suggestions to make things a bit cleaner.
>>
>> Cheers,
>> Chris
>>
>> P.S.  I think SableVM really needs some sort of documentation 
>> standards (javadoc?) as more and more people start contributing.
>>
>>------------------------------------------------------------------------
>>
>>This file explains what the various other files in this directory contain,
>>although may in the future contain other information as to how the VM is
>>organized in terms of source files, where to get started when looking at
>>the VM, etc.  Files generated from macros are not included.
>>
>>bootstrap.m4.c:
>>	get ready to create java/lang/Class instances
>>	create a whole bunch of fundamental classes (lots of exception classes)
>>
>>buffer.m4.c:
>>buffer.m4.h:
>>	dependence buffer for speculative execution
>>
>>cast.list:
>>	list of all macro supported casts possible within SableVM C source code
>>	( _svmt_cp_info, _svmt_attribute_info, _svmt_type_info, jobject,
>>	 jarray, _svmt_native_ref, etc.)
>>
>>cast.m4.c:
>>	macro m4svm_cast($1,$2,$3) to cast $3 to $2
>>
>>cl_alloc.list:
>>	list of method declarations for class memory allocation
>>
>>cl_alloc.m4.c:
>>cl_alloc.m4.h:
>>	macros to implement methods declared in cl_alloc.list
>>
>>class_file_parser.h:
>>	short C preprocessor macro to parse class files.  not really sure
>>	why this is necessary.
>>
>>class_loader.c:
>>	class loading, including that done during bootstrapping and
>>	invoked by the user code
>>
>>class_loader_memory_manager.c:
>>class_loader_memory_manager.h:
>>	the class loader has its own memory manager (see Ch. 3 of thesis)
>>
>>constants.h:
>>	constants defined within SableVM for:
>>		type state
>>		array types
>>		constant pool tags
>>		access flags
>>		types
>>		signal codes
>>		2 specific constants
>>		interpreter flags
>>		stack map types
>>		thread status
>>		instructions
>>
>>direct_threaded.m4:
>>	single line macro definition (why is this file necessary?)
>>
>>error.c:
>>	code for using signal handlers to throw exceptions
>>
>>error.list:
>>	list of exceptions and errors handled by SableVM
>>
>>error_bits.m4.h:
>>error_classes.m4.h:
>>error_init_methods.m4.h:
>>error_instances.m4.h:
>>	very short multicallable macros to declare error types.
>>	not sure why all four of these files exist ... they are
>>	very similar and all declare macros of the same name.
>>	
>>error_throwing.c:
>>	macro to implement throwing specific errors
>>
>>fatal.c:
>>fatal.h:
>>	code to throw fatal errors that cause abortion of the VM
>>
>>gc_copying.c:
>>	semi-space Cheney copying collector
>>
>>gc_generational:
>>	currently broken generational GC
>>
>>gc_none.c:
>>	no GC memory management (just allocate heap and operate until
>>	it is full).
>>
>>global_alloc.list:
>>	list of method declarations for global allocations
>>
>>global_alloc.m4.c:
>>global_alloc.m4.h:
>>	macros to implement malloc, calloc, and free methods as specified
>>	in global_alloc.list
>>
>>global_refs.c:
>>global_refs.h:
>>	code to create and free native globals (in what context?).  requires
>>	synchronization on vm->global_mutex.
>>	
>>heap_manager.c:
>>	code to get object hashcodes and include GC's.
>>	it seems that the code at the end of this file is out of date, if not
>>	the whole file.
>>
>>heap_manager.h:
>>	empty file essentially ...
>>
>>initialization.c:
>>	class initialization code.
>>
>>inlined_threaded.m4:
>>	single line macro definition (why is this file necessary?)	
>>
>>instructions.m4.c:
>>	implementations of all bytecodes
>>
>>instructions_preparation.m4:
>>	single line macro definition (why is this file necessary?)	
>>	
>>instructions_preparation.m4.c:
>>	macros for preparing switch-, direct-, and inlined-threaded instructions
>>
>>instructions_switch.m4:
>>	single line macro definition (why is this file necessary?)	
>>	
>>instructions_switch.m4.c	
>>	another switch-threaded macro, confused about this file.
>>
>>interpreter.c:
>>interpreter.h:
>>	the main interpreter engine that can be compiled to run in
>>	switch-, direct-, or inlined-threaded modes.
>>
>>invoke_interface.c:
>>invoke_interface.h:
>>	JNI methods to create and destroy VM's, with AttachCurrentThread,
>>	DetachCurrentThread, and GetEnv still unimplemented.
>>
>>java_lang_*:
>>	JNI methods for java.lang.* ... some of these are fundamental to VM
>>	operation, others are not and remain to be implemented.
>>
>>jnidefs.h:
>>	definitions of jobject, jarray, jfieldID, and jmethodID.  why do
>>	these get their own special file, instead of being included in
>>	types.h or jni.h?
>>
>>lib_init.c:
>>	not really sure, seems to be only for calling lt_dlinit(), and
>>	ensuring that it only gets called once.
>>
>>libsablevm.c:
>>	big include file for compilation to a single object (see Makefile.am)
>>
>>link.c:
>>link.h:
>>	class, array, and type linking.
>>
>>local_refs.c:
>>local_refs.h:
>>	similar to global_refs.c but for locals.
>>
>>macros.c:
>>	casting functions and _svmf_is_same_object.  not really sure why
>>	these cast functions are necessary, can't we generate them using
>>	cast.list and cast.m4.c ... maybe this file is obsolete.
>>	
>>macros.h:
>>	some C preprocessor macros.  seems like these are probably
>>	obsolete given the widespread use of m4 now.
>>
>>macros.m4:
>>	basic m4 macros for use within the rest of the VM.  learning how
>>	m4 works is a good idea if you want to understand SableVM.
>>
>>Makefile.am:
>>	input file for automake
>>
>>method_invoke.list:
>>	declarations of VM-critical nonvirtual and static methods.  not
>>	sure what the "specific" methods are all about.
>>
>>method_invoke.m4.c:
>>method_invoke.m4.h:
>>	macros containing the bodies of methods declared in method_invoke.list
>>
>>native.c:
>>native.h:
>>	code to enable native method execution in SableVM
>>
>>native_interface.c:
>>	implementation of all JNI methods
>>
>>native_interface.h:
>>	very small file defining the JNINativeInterface extern.
>>
>>new_instance.c:
>>new_instance.h:
>>	methods to create objects and arrays.
>>
>>prepare.c:
>>prepare.h:
>>	prepare interfaces and classes, but not method bodies.
>>
>>prepare_code.c:
>>prepare_code.h:
>>	implementation of recursive locks on top of pthread
>>
>>README:
>>	this file :-)
>>
>>resolve.c:
>>resolve.h:
>>	code to resolve methods, classes, and interfaces when found
>>	in bytecode during execution.
>>
>>splay_tree.list:
>>	list of splay tree kinds used within SableVM (there are 4, one
>>        each for types, gc_maps, sequences, and interface_method_signatures). 
>>
>>splay_tree.m4.c:
>>	macros to generate splay tree code for the kinds listed in
>>	splay_tree.list:
>>
>>switch_threaded.m4
>>	single line macro definition (why is this file necessary?)
>>
>>system.c
>>	system specific implementations
>>
>>system.h
>>	system specific header
>>
>>thread.c:
>>thread.h:
>>	thread management functions (initialization, stopping for GC, etc.)
>>
>>types.h:
>>	This file is really at the heart of SableVM.  It defines the data
>>   	structures used in SableVM.  When looking at the VM for a first
>>   	time, you should spend some time reading this file.
>>
>>util.h:
>>	a few short utility C preprocessor macros ... not sure if these
>>	are defined elsewhere or not.  for example, it seems that the
>>	memset() wrapper should go into global_alloc.m4.c with the
>>	other memory management stuff
>>
>>util.m4.c:
>>	some put/get macros.  seems like they complement those in util1.c
>>	but I'm not sure.
>>
>>util1.c:
>>	various utilities for working with C code and for getting
>>	stack traces.  not sure why the put/get_BOOLEAN/REFERENCE_field/static
>>	methods are in here ...
>>util2.c:
>>	more utility code, this time mostly for working with Java data
>>	structures.  seems to me like the Java stuff should go in one util
>>	file and the C stuff in another.
>>
>>verifier.c:
>>verifier.h:
>>	bytecode verifier (not fully implemented).
>>
>>vm_args.m4.c:
>>	macros to handle arguments to the VM from the command line (or from
>>	whoever creates it?)
>>
>>vmlib.c:
>>vmlib.h:
>>	some JNI methods ... not sure if this file is perhaps obsolete (or at
>>	least part of it, because it seems some java.lang.* stuff is in here.
>>	the header file is empty.
>>
>>
>>
>>
>>  
>>

Re: [Sablevm-developer] README for libsablevm

[Chris P. <chr...@ma...>]

Sorry ... the buffer.m4.c and buffer.m4.h files shouldn't be in the 
README ... that's stuff I'm working on and I forgot to take it out.

Cheers,
Chris

Chris Pickett wrote:

> Hi,
>
> I looked through all files in libsablevm this morning and took notes.  
> The result is a README file in my local CVS.  It would be nice if this 
> could be cleaned up and then committed to the main repository ... it 
> can overwhelming when starting to look at the VM, and it's good to 
> have a reference.  Perhaps some tips as to where to get started (e.g. 
> looking at types.h and jni.h, reading the JNI / JVM specs) would also 
> be helpful.
> Although I couldn't give good descriptions for everything, this is 
> better than nothing at all IMHO.  It would also be nice if currently 
> unused files (e.g. gc_generational.c) were moved into a directory 
> called dev, or just removed from the CVS if they're obsolete.  Also, 
> it would be nice to combine some of the very small files into larger 
> files.  Finally, perhaps the java_* stuff should be moved to a 
> separate folder.  Just some suggestions to make things a bit cleaner.
>
> Cheers,
> Chris
>
> P.S.  I think SableVM really needs some sort of documentation 
> standards (javadoc?) as more and more people start contributing.
>
>------------------------------------------------------------------------
>
>This file explains what the various other files in this directory contain,
>although may in the future contain other information as to how the VM is
>organized in terms of source files, where to get started when looking at
>the VM, etc.  Files generated from macros are not included.
>
>bootstrap.m4.c:
>	get ready to create java/lang/Class instances
>	create a whole bunch of fundamental classes (lots of exception classes)
>
>buffer.m4.c:
>buffer.m4.h:
>	dependence buffer for speculative execution
>
>cast.list:
>	list of all macro supported casts possible within SableVM C source code
>	( _svmt_cp_info, _svmt_attribute_info, _svmt_type_info, jobject,
>	 jarray, _svmt_native_ref, etc.)
>
>cast.m4.c:
>	macro m4svm_cast($1,$2,$3) to cast $3 to $2
>
>cl_alloc.list:
>	list of method declarations for class memory allocation
>
>cl_alloc.m4.c:
>cl_alloc.m4.h:
>	macros to implement methods declared in cl_alloc.list
>
>class_file_parser.h:
>	short C preprocessor macro to parse class files.  not really sure
>	why this is necessary.
>
>class_loader.c:
>	class loading, including that done during bootstrapping and
>	invoked by the user code
>
>class_loader_memory_manager.c:
>class_loader_memory_manager.h:
>	the class loader has its own memory manager (see Ch. 3 of thesis)
>
>constants.h:
>	constants defined within SableVM for:
>		type state
>		array types
>		constant pool tags
>		access flags
>		types
>		signal codes
>		2 specific constants
>		interpreter flags
>		stack map types
>		thread status
>		instructions
>
>direct_threaded.m4:
>	single line macro definition (why is this file necessary?)
>
>error.c:
>	code for using signal handlers to throw exceptions
>
>error.list:
>	list of exceptions and errors handled by SableVM
>
>error_bits.m4.h:
>error_classes.m4.h:
>error_init_methods.m4.h:
>error_instances.m4.h:
>	very short multicallable macros to declare error types.
>	not sure why all four of these files exist ... they are
>	very similar and all declare macros of the same name.
>	
>error_throwing.c:
>	macro to implement throwing specific errors
>
>fatal.c:
>fatal.h:
>	code to throw fatal errors that cause abortion of the VM
>
>gc_copying.c:
>	semi-space Cheney copying collector
>
>gc_generational:
>	currently broken generational GC
>
>gc_none.c:
>	no GC memory management (just allocate heap and operate until
>	it is full).
>
>global_alloc.list:
>	list of method declarations for global allocations
>
>global_alloc.m4.c:
>global_alloc.m4.h:
>	macros to implement malloc, calloc, and free methods as specified
>	in global_alloc.list
>
>global_refs.c:
>global_refs.h:
>	code to create and free native globals (in what context?).  requires
>	synchronization on vm->global_mutex.
>	
>heap_manager.c:
>	code to get object hashcodes and include GC's.
>	it seems that the code at the end of this file is out of date, if not
>	the whole file.
>
>heap_manager.h:
>	empty file essentially ...
>
>initialization.c:
>	class initialization code.
>
>inlined_threaded.m4:
>	single line macro definition (why is this file necessary?)	
>
>instructions.m4.c:
>	implementations of all bytecodes
>
>instructions_preparation.m4:
>	single line macro definition (why is this file necessary?)	
>	
>instructions_preparation.m4.c:
>	macros for preparing switch-, direct-, and inlined-threaded instructions
>
>instructions_switch.m4:
>	single line macro definition (why is this file necessary?)	
>	
>instructions_switch.m4.c	
>	another switch-threaded macro, confused about this file.
>
>interpreter.c:
>interpreter.h:
>	the main interpreter engine that can be compiled to run in
>	switch-, direct-, or inlined-threaded modes.
>
>invoke_interface.c:
>invoke_interface.h:
>	JNI methods to create and destroy VM's, with AttachCurrentThread,
>	DetachCurrentThread, and GetEnv still unimplemented.
>
>java_lang_*:
>	JNI methods for java.lang.* ... some of these are fundamental to VM
>	operation, others are not and remain to be implemented.
>
>jnidefs.h:
>	definitions of jobject, jarray, jfieldID, and jmethodID.  why do
>	these get their own special file, instead of being included in
>	types.h or jni.h?
>
>lib_init.c:
>	not really sure, seems to be only for calling lt_dlinit(), and
>	ensuring that it only gets called once.
>
>libsablevm.c:
>	big include file for compilation to a single object (see Makefile.am)
>
>link.c:
>link.h:
>	class, array, and type linking.
>
>local_refs.c:
>local_refs.h:
>	similar to global_refs.c but for locals.
>
>macros.c:
>	casting functions and _svmf_is_same_object.  not really sure why
>	these cast functions are necessary, can't we generate them using
>	cast.list and cast.m4.c ... maybe this file is obsolete.
>	
>macros.h:
>	some C preprocessor macros.  seems like these are probably
>	obsolete given the widespread use of m4 now.
>
>macros.m4:
>	basic m4 macros for use within the rest of the VM.  learning how
>	m4 works is a good idea if you want to understand SableVM.
>
>Makefile.am:
>	input file for automake
>
>method_invoke.list:
>	declarations of VM-critical nonvirtual and static methods.  not
>	sure what the "specific" methods are all about.
>
>method_invoke.m4.c:
>method_invoke.m4.h:
>	macros containing the bodies of methods declared in method_invoke.list
>
>native.c:
>native.h:
>	code to enable native method execution in SableVM
>
>native_interface.c:
>	implementation of all JNI methods
>
>native_interface.h:
>	very small file defining the JNINativeInterface extern.
>
>new_instance.c:
>new_instance.h:
>	methods to create objects and arrays.
>
>prepare.c:
>prepare.h:
>	prepare interfaces and classes, but not method bodies.
>
>prepare_code.c:
>prepare_code.h:
>	implementation of recursive locks on top of pthread
>
>README:
>	this file :-)
>
>resolve.c:
>resolve.h:
>	code to resolve methods, classes, and interfaces when found
>	in bytecode during execution.
>
>splay_tree.list:
>	list of splay tree kinds used within SableVM (there are 4, one
>        each for types, gc_maps, sequences, and interface_method_signatures). 
>
>splay_tree.m4.c:
>	macros to generate splay tree code for the kinds listed in
>	splay_tree.list:
>
>switch_threaded.m4
>	single line macro definition (why is this file necessary?)
>
>system.c
>	system specific implementations
>
>system.h
>	system specific header
>
>thread.c:
>thread.h:
>	thread management functions (initialization, stopping for GC, etc.)
>
>types.h:
>	This file is really at the heart of SableVM.  It defines the data
>   	structures used in SableVM.  When looking at the VM for a first
>   	time, you should spend some time reading this file.
>
>util.h:
>	a few short utility C preprocessor macros ... not sure if these
>	are defined elsewhere or not.  for example, it seems that the
>	memset() wrapper should go into global_alloc.m4.c with the
>	other memory management stuff
>
>util.m4.c:
>	some put/get macros.  seems like they complement those in util1.c
>	but I'm not sure.
>
>util1.c:
>	various utilities for working with C code and for getting
>	stack traces.  not sure why the put/get_BOOLEAN/REFERENCE_field/static
>	methods are in here ...
>util2.c:
>	more utility code, this time mostly for working with Java data
>	structures.  seems to me like the Java stuff should go in one util
>	file and the C stuff in another.
>
>verifier.c:
>verifier.h:
>	bytecode verifier (not fully implemented).
>
>vm_args.m4.c:
>	macros to handle arguments to the VM from the command line (or from
>	whoever creates it?)
>
>vmlib.c:
>vmlib.h:
>	some JNI methods ... not sure if this file is perhaps obsolete (or at
>	least part of it, because it seems some java.lang.* stuff is in here.
>	the header file is empty.
>
>
>
>
>  
>

[Sablevm-developer] README for libsablevm

[Chris P. <chr...@ma...>]

Hi,

I looked through all files in libsablevm this morning and took notes.  
The result is a README file in my local CVS.  It would be nice if this 
could be cleaned up and then committed to the main repository ... it can 
overwhelming when starting to look at the VM, and it's good to have a 
reference.  Perhaps some tips as to where to get started (e.g. looking 
at types.h and jni.h, reading the JNI / JVM specs) would also be helpful. 

Although I couldn't give good descriptions for everything, this is 
better than nothing at all IMHO.  It would also be nice if currently 
unused files (e.g. gc_generational.c) were moved into a directory called 
dev, or just removed from the CVS if they're obsolete.  Also, it would 
be nice to combine some of the very small files into larger files.  
Finally, perhaps the java_* stuff should be moved to a separate folder.  
Just some suggestions to make things a bit cleaner.

Cheers,
Chris

P.S.  I think SableVM really needs some sort of documentation standards 
(javadoc?) as more and more people start contributing. 

Re: [Sablevm-developer] How Thread.interrupt()?

[Prof. E. M. G. <eti...@uq...>]

interrupt() is a relatively "soft" action; It only interrupts a thread
at well identified points.  Blocking IO calls won't be interrupted,
for example.

I was my impression, when I looked at it a long while back, that it
could be mostly implemented in Java, with minimal native VM support.

For example, the status could be a private boolean instance field, and
interrupted() can simply check it.  Of course, VM support is required
to send a signal to a sleeping thread.  If I am right, the algorithm
would be something like:

{
  interrupted_status = true;
  send_a_possibly_ignored_signal_that_would_awakens_a_sleping_thread()
}

Etienne

On Wed, Mar 05, 2003 at 12:50:32PM -0800, Archie Cobbs wrote:
> Archie Cobbs wrote:
> > What strategy did you have in mind for implementing Thread.interrupt(),
> > in a reasonably portable way? Seems like the only way to do it is to
> > somehow route a signal to the appropriate thread.
> > 
> > E.g. if a thread is sleeping in the read() system call, the only way
> > to wake it up is via a signal (causing read() to return a short count
> > or EINTR). Is there a clean way to do this?
> 
> Um, nevermind.. I was confused about what interrupt() does...
> 
> -Archie
> 
> __________________________________________________________________________
> Archie Cobbs     *     Precision I/O      *     http://www.precisionio.com
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer
> 

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] How Thread.interrupt()?

[David <db...@cs...>]

On Wed, Mar 05, 2003 at 12:50:32PM -0800, Archie Cobbs wrote:
> Archie Cobbs wrote:
> > What strategy did you have in mind for implementing Thread.interrupt(=
),
> > in a reasonably portable way? Seems like the only way to do it is to
> > somehow route a signal to the appropriate thread.
> >=20
> > E.g. if a thread is sleeping in the read() system call, the only way
> > to wake it up is via a signal (causing read() to return a short count
> > or EINTR). Is there a clean way to do this?
>=20
> Um, nevermind.. I was confused about what interrupt() does...
>=20

Actually, the functionality you described is the only thing missing
in my Process.waitFor() implementation (a more complete version
that I will send eventually).

The thread waits on the waitpid() sys call, but if it is interrupt()ed,
the sys call will have to be interrupted.

David


> -Archie
>=20
> _______________________________________________________________________=
___
> Archie Cobbs     *     Precision I/O      *     http://www.precisionio.=
com
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debu=
gger=20
> for complex code. Debugging C/C++ programs can leave you feeling lost a=
nd=20
> disoriented. TotalView can help you find your way. Available on major U=
NIX=20
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer

--=20

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

Re: [Sablevm-developer] How Thread.interrupt()?

[Archie C. <ar...@de...>]

Archie Cobbs wrote:
> What strategy did you have in mind for implementing Thread.interrupt(),
> in a reasonably portable way? Seems like the only way to do it is to
> somehow route a signal to the appropriate thread.
> 
> E.g. if a thread is sleeping in the read() system call, the only way
> to wake it up is via a signal (causing read() to return a short count
> or EINTR). Is there a clean way to do this?

Um, nevermind.. I was confused about what interrupt() does...

-Archie

__________________________________________________________________________
Archie Cobbs     *     Precision I/O      *     http://www.precisionio.com

[Sablevm-developer] How Thread.interrupt()?

[Archie C. <ar...@de...>]

Etienne,

What strategy did you have in mind for implementing Thread.interrupt(),
in a reasonably portable way? Seems like the only way to do it is to
somehow route a signal to the appropriate thread.

E.g. if a thread is sleeping in the read() system call, the only way
to wake it up is via a signal (causing read() to return a short count
or EINTR). Is there a clean way to do this?

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs     *     Precision I/O      *     http://www.precisionio.com

Re: [Sablevm-developer] How to change the instructions_preparation_inlined_threaded.c

[Prof. E. M. G. <eti...@uq...>]

Hi Dayong,

You simply need to modify the m4 macro called
m4svm_instruction_inlined_threaded in the file
src/libsablevm/instructions_preparation.m4.c.

To better understand, you might want to read the comments in the file
macros.m4, more specifically, the comment of:

----------------------------------------------------------------------
define macro
----------------------------------------------------------------------

Have fun!

Etienne

On Tue, Mar 04, 2003 at 11:17:27PM -0500, Dayong Gu wrote:
> Hi,
> 
> Could u show me a way to change the code for each bytecode in
> instructions_preparation_inlined_threaded.c?
> I want to add several lines of  code to each implementation of these
> bytecodes.
> 
> For example:
> For each bytecode, at current we have:
> ...
> END_BIPUSH:
> /* dispatch*/
> goto *((pc++)->implementation);
> 
> I want to add some codes before  goto *((pc++)->implementation);
> for each bytecode.
> 
> 
> Thank u!
> 
> Cheers,
> Dayong
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> for complex code. Debugging C/C++ programs can leave you feeling lost and 
> disoriented. TotalView can help you find your way. Available on major UNIX 
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

[Sablevm-developer] How to change the instructions_preparation_inlined_threaded.c

[Dayong Gu <dg...@cs...>]

Hi,

Could u show me a way to change the code for each bytecode in
instructions_preparation_inlined_threaded.c?
I want to add several lines of  code to each implementation of these
bytecodes.

For example:
For each bytecode, at current we have:
...
END_BIPUSH:
/* dispatch*/
goto *((pc++)->implementation);

I want to add some codes before  goto *((pc++)->implementation);
for each bytecode.


Thank u!

Cheers,
Dayong

Re: [Sablevm-developer] Does SableVM actually work? (on XYZ arch)

[Grzegorz B. P. <ga...@de...>]

W li=B6cie z =B6ro, 26-02-2003, godz. 15:43, Prof. Etienne M. Gagnon pisze:=
=20
> But on the short term, I think HelloWorld is pretty good because (probabl=
y=20
> better than you think):
Yes, this HelloWorld ran in verbose mode shows pretty good how bloated
Java is _:-)_

I also ITPed mauve with testing SableVM in mind, but it seems it'll take
longer time before I have no more important TODOs to actually start the
packaging, so if somebody would like to take over - you're welcomed [0].

> I really think that HelloWorld ought to be enough to include into a:
>    $ ./configure ; make ; make test ; make install
> build precedure.
Agreed.

However I hope that you'll keep the "no binaries in source" ideology and
you won't put HelloWorld.jar binary into source tree. Instead IMO
HelloWorld should be compiled (with jikes preferably or with
javac if no jikes is found), maybe [fast]jar'ed and then executed
(it'd also test if the jikes/javac is suitable for SableVM).

Cheers,

					Grzegorz B. Prokopski

[0] I am also preparing to give away other of my existing packages, like
ArgoUML Java UML Modeller. Contact me privately if you're interested.

--=20
Grzegorz B. Prokopski <ga...@de...>
Debian http://www.debian.org/

[Sablevm-developer] .cvsignore

[David <db...@cs...>]

Hello,

This is a suggestion.

It would be good to have .cvsignore files for all
automatically generated files in the SableVM repository.
I have my own collection and I could send them to have
them checkin.

David

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

Re: [Sablevm-developer] REQUEST: Please remind me of any patch you previously posted.

[David <db...@cs...>]

Hi,

I shrinked the Mac OS X patch one third its original size.  I don't think=
 we
have a huge Mac OS X user based, but anyway here is the new version for
people interested.

Notes:
- Most changes are for the classpath native library
- Changed to SableVM are syntax changes in assembler code since
  Apple uses a different assembler.  These changes make both
  assemblers happy.
    In particular, ';' cannot be used to separate multiple
    instructions.  (If it is used only the first one is used!)
- Note: The spaces between ::: in:
    __asm__ __volatile__ ("isync" : : : "memory");
  are necessary.  It produces a syntax error on Mac OS X.
  (Maybe because has special meaning in objective C?, there may be an
   option to fix this but anyway.)
- Also, malloc.h is at some other location but SableVM does not seem
  to include it directly.  So no problem there.

I am using SableVM on GNU/Linux PPC with these changes and I didn't have
any problem so far.

Also, the program to compute the alignment SVM_ALIGNMENT gives 4 on OS X
and 8 on GNU/Linux.  The convention used by Apple says that it can be
both 4 or 8 and if the double is at the beginning of the struct, it is
aligned on 8 as well as the structure.  So I just kept it to 8.


David

On Mon, Feb 24, 2003 at 12:09:37AM -0500, Prof. Etienne M. Gagnon wrote:
> Hi there.
>=20
> I'd like to start applying patches that have previously been posted to
> this mailing-list.  If you any any pending patch which is NOT already
> included as an attachment to a bug report, please do one of the
> following:
>=20
> 1 - submit a bug report with the patch as attachment, or
>=20
> 2 - resend a message to this list with the patch as attachment.
>=20
> Thanks,
>=20
> Etienne
>=20
> --=20
> Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
> SableVM:                                       http://www.sablevm.org/
> SableCC:                                       http://www.sablecc.org/



--=20

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

Re: [Sablevm-developer] question - vm->instructions

[Prof. E. M. G. <eti...@uq...>]

David B=E9langer wrote:
> Hi,
>=20
> I would like to know the reason behind having the initialization of
> vm->instructions array done in _svmf_interpreter.  Could it just not
> be done outside avoid both the null-checking and sigfault.=20

If it was possible, you can be sure I would have done so!  The problem is=
 that=20
labels are of a local scope. e.g.

void foo()
{
   label1:  return;
}

void bar()
{
   void **value =3D &&label1;  /* <=3D=3D compilation error! */
}

Have fun!

Etienne


--=20
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

[Sablevm-developer] question - vm->instructions

[David <db...@cs...>]

Hi,

I would like to know the reason behind having the initialization of
vm->instructions array done in _svmf_interpreter.  Could it just not
be done outside avoid both the null-checking and sigfault.  Unless
it is initialized several time (why would it be?), I do not see
why it could just not be done after allocating the mem for the
array (in invoke_interface.c JNI_CreateJavaVM (outside of
_svmf_interpreter)) and then we could just avoid the sigfault
(or null-check) on initialization of vm->instructions.

David

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

Re: [Sablevm-developer] Does SableVM actually work? (on XYZ arch)

[Archie C. <ar...@de...>]

Bruno Dufour wrote:
> 	Anyone can contribute benchmarks and/or suggestions for Ashes2 (and is 
> encouraged to do so). I am still trying to finalize to Ashes2 language 

The kaffe project has developed a good suite of test Java programs
over the years that test lots of tricky stuff like class loading,
etc. Many tests may need to be generalized but there is a lot of
good "testing wisdom" embedded in them. They're in the test/regression
subdirectory.

Cheers,
-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com

Re: [Sablevm-developer] Does SableVM actually work? (on XYZ arch)

[Bruno D. <bru...@ma...>]

Hi,

	Etienne is right. Even though it is not really apparent, the work that 
happens behind the scenes to execute Hello World is indeed significant. Try 
profiling it and you'll see for yourself. 

	I am currently responsible for creating the second generation of Sable's 
Ashes benchmark suite (http://www.sable.mcgill.ca/ashes/), which is going to 
be a complete re-design of the old one. My goal is to integrate a VM testing 
suite into Ashes2. It would contain, as Etienne suggested, micro benchmarks 
that would test every possible bytecode, as well as some more advanced ones 
to test more advanced features of a Java VM. This includes threading issues. 
As far as threading issues are concerned, I some nice and simple 
multi-threaded benchmarks, such as RollerCoaster (a classic in concurrency), 
that should do the trick.

	Anyone can contribute benchmarks and/or suggestions for Ashes2 (and is 
encouraged to do so). I am still trying to finalize to Ashes2 language 
specification at this point. Suggestions can be send to my e-mail address if 
you judge that they don't belong to this list. As soon as I have something 
that looks stable enough, I'll create a temporary web page so that people can 
keep track of what the status of Ashes2 is.

Cheers,

	Bruno

On Wednesday 26 February 2003 14:43 pm, Prof. Etienne M. Gagnon wrote:
> Grzegorz B. Prokopski wrote:
> > The problem is that I don't think running HelloWorld is enough to be
> > sure that SableVM is actually properly ported to every single arch.
>
> An extensive test suite would really be welcome. Such a test suite would
> cover all bytecode instructions (in fact, it should cover all SableVM
> internal instruction codes), and should eventually also test things like
> vm<->library interface, etc.  I am planning to get some of this work done
> through future internships by undergraduate students, but it will take some
> time to get it done.  Getting "mauve" to test SableVM would be a first step
> toward building this bigger suite (which would include mauve as a
> subcomponent).
>
> But on the short term, I think HelloWorld is pretty good because (probably
> better than you think):
>
> 1- it triggers the loading and initialization of approximately 150 classes,
>
> 2- it causes the execution of a significant amount of code, using most
> bytecode instructions,
>
> 3- it uses the JNI interface (native->Java & Java->native) [good for making
> sure libffi works],
>
> 4- it even tests synchronization primitives, even though it does not spawn
> multiple threads, because many class library methods are either
> synchronized, or they contain explicit synchronized(obj){...} blocks.
>
> > 1. Write simple java program especially targetted at testing SableVM's
> > architecture specific pieces, I mean: ...
> >
>  > I don't have enough knowledge of
> >
> > Java to write such program myself...
>
> It is probably a good time to go to the book store and buy one of the
> countless Java books. ;-)
>
> > 2. ... I belive SableCC uses many threads
>
> Unfortunately it doesn't.  Soot does, but it is quite a big piece of
> software, so I'm not sure you want to include it as a simple test in a
> build process.
>
> I really think that HelloWorld ought to be enough to include into a:
>    $ ./configure ; make ; make test ; make install
> build precedure.
>
>
> Have fun!
>
> Etienne

Re: [Sablevm-developer] Does SableVM actually work? (on XYZ arch)

[Prof. E. M. G. <eti...@uq...>]

Grzegorz B. Prokopski wrote:
> The problem is that I don't think running HelloWorld is enough to be
> sure that SableVM is actually properly ported to every single arch.

An extensive test suite would really be welcome. Such a test suite would cover 
all bytecode instructions (in fact, it should cover all SableVM internal 
instruction codes), and should eventually also test things like vm<->library 
interface, etc.  I am planning to get some of this work done through future 
internships by undergraduate students, but it will take some time to get it 
done.  Getting "mauve" to test SableVM would be a first step toward building 
this bigger suite (which would include mauve as a subcomponent).

But on the short term, I think HelloWorld is pretty good because (probably 
better than you think):

1- it triggers the loading and initialization of approximately 150 classes,

2- it causes the execution of a significant amount of code, using most bytecode 
instructions,

3- it uses the JNI interface (native->Java & Java->native) [good for making sure 
libffi works],

4- it even tests synchronization primitives, even though it does not spawn 
multiple threads, because many class library methods are either synchronized, or 
they contain explicit synchronized(obj){...} blocks.

> 1. Write simple java program especially targetted at testing SableVM's
> architecture specific pieces, I mean: ...
 > I don't have enough knowledge of
> Java to write such program myself...

It is probably a good time to go to the book store and buy one of the countless 
Java books. ;-)

> 2. ... I belive SableCC uses many threads

Unfortunately it doesn't.  Soot does, but it is quite a big piece of software, 
so I'm not sure you want to include it as a simple test in a build process.

I really think that HelloWorld ought to be enough to include into a:
   $ ./configure ; make ; make test ; make install
build precedure.


Have fun!

Etienne

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: Release [was: Re: [Sablevm-developer] Alpha inlined threading works now, but...]

[Archie C. <ar...@de...>]

Prof. Etienne M. Gagnon wrote:
> > Also, in case anyone doesn't know, you can still use jikes 1.18
> > with SableVM. Just tell it to produce the older classfiles by using
> > the -target command line option.
> > 
> > E.g.: jikes -target 1.2 Foo.java
> 
> This does not work for me, at least.  I continue to get:
> 
> $ sablevm -Y SomeClass
> *** Couldn't bind native method Java_java_lang_VMClassLoader_nativeCreateArray ***
> *** or Java_java_lang_VMClassLoader_nativeCreateArray__Ljava_lang_String_2Z ***
> java.lang.NoClassDefFoundError: [Ljava.lang.ClassLoader;
>         at java.lang.ClassLoader.class$(ClassLoader.java:0)
>         at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:916)
>         at java.lang.ClassLoader.static{}(ClassLoader.java:155)
>         at java.lang.Class.step8(Class.java)
>         at java.lang.Class.initialize(Class.java:150)
>         at java.lang.VirtualMachine.main(VirtualMachine.java:78)

Interesting...

Well, admittedly I didn't actually try this.. so I guess SableVM must
implement a few more native methods before this can work... it's not
clear whether this is a bug in the jikes -target flag, or just jikes
triggering an "unimplemented feature" bug in SableVM.

-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com

Re: Release [was: Re: [Sablevm-developer] Alpha inlined threading works now, but...]

[Prof. E. M. G. <eti...@uq...>]

On Mon, Feb 24, 2003 at 01:35:19PM -0800, Archie Cobbs wrote:
> Also, in case anyone doesn't know, you can still use jikes 1.18
> with SableVM. Just tell it to produce the older classfiles by using
> the -target command line option.
>=20
> E.g.: jikes -target 1.2 Foo.java

This does not work for me, at least.  I continue to get:

$ sablevm -Y SomeClass
*** Couldn't bind native method Java_java_lang_VMClassLoader_nativeCreateAr=
ray ***
*** or Java_java_lang_VMClassLoader_nativeCreateArray__Ljava_lang_String_2Z=
 ***
java.lang.NoClassDefFoundError: [Ljava.lang.ClassLoader;
        at java.lang.ClassLoader.class$(ClassLoader.java:0)
        at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:916)
        at java.lang.ClassLoader.static{}(ClassLoader.java:155)
        at java.lang.Class.step8(Class.java)
        at java.lang.Class.initialize(Class.java:150)
        at java.lang.VirtualMachine.main(VirtualMachine.java:78)
$

Etienne


--=20
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: Release [was: Re: [Sablevm-developer] Alpha inlined threading works now, but...]

[Archie C. <ar...@de...>]

Prof. Etienne M. Gagnon wrote:
> > FWIW, I think practically speaking you could modify SableVM to accept
> > classfiles with major version numbers up to 48 without any problems.
> 
> I did this.  We still have to fill a couple of call-back (JNI) hooks for
> Jikes 1.18 to work.

Also, in case anyone doesn't know, you can still use jikes 1.18
with SableVM. Just tell it to produce the older classfiles by using
the -target command line option.

E.g.: jikes -target 1.2 Foo.java

-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com

[Sablevm-developer] Does SableVM actually work? (on XYZ arch)

[Grzegorz B. P. <ga...@de...>]

Hello!

It seems that thanks to the architecture of SableVM it is very easy to
add support for new arches w/o inlined engine and slightly harder with
it.

The problem is that I don't think running HelloWorld is enough to be
sure that SableVM is actually properly ported to every single arch.

So there are two approches I can see:

1. Write simple java program especially targetted at testing SableVM's
architecture specific pieces, I mean: a) threads synchronization and
b) inlineability of instructions. I don't have enough knowledge of
Java to write such program myself, so if you think that's the right
approach to the presented problem - would you be so kind to write sth.
like that for me (and other persons doing ports)?

2. Use an existing but complicated program, that is known as good
tester of JVMs issues. I remember using SableCC on alpha for that,
when doing first port w/ Etienne. I belive SableCC uses many threads
etc. and if we had problems w/ compare&swap function - it would make
it visible (right?).
But I never actually used SableCC (only pccts long time ago) so if
you could provide me with a way of testing SableVM using SableCC
(or any other app at your opinion) - it would be great.


I think I could even encode such test case in build scripts of debian
SableVM package and we then could simply look at the autobuilders output
to check whether the porting is actually successuful or not (but the
test case would need to be either a simple program, or some app already
available in Debian).

Cheers,

					Grzegorz B. Prokopski

PS: Having tests like above - I think I can do some of the ports
"blindly" w/o even accessing the developer machines of specific
architecture. It is a gain because to use them for porting I  need to
first ask debian-admins to install build dependencies of SableVM on
every machine separately which takes time and highers their burden.
I think I could just ask them for this only WHEN some problems occured
and my "blind" porting didn't succeed.

Mind you that we still have about 7 arches on the TODO list.
--=20
Grzegorz B. Prokopski <ga...@de...>
Debian http://www.debian.org/

Re: Release [was: Re: [Sablevm-developer] Alpha inlined threading works now, but...]

[Prof. E. M. G. <eti...@uq...>]

Archie Cobbs wrote:
> FWIW, I think practically speaking you could modify SableVM to accept
> classfiles with major version numbers up to 48 without any problems.

I did this.  We still have to fill a couple of call-back (JNI) hooks for Jikes 
1.18 to work.

Thanks for providing the Jikes info below.

Etienne

> 
> I asked on the jikes mailing list about their changes and what spec
> they were reading from. Nobody could produce the spec, but I did get
> some useful info (see below).
> 
> -Archie
> 
> __________________________________________________________________________
> Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com
> 
> 
>>From jik...@ww... Sat Feb 15 10:20:01 2003
>>From: Eric Blake <eb...@em...>
>>Subject: Re: [Jikes-dev] New class file format
>>To: jik...@ww...
>>Message-ID: <3E4...@em...>
>>MIME-Version: 1.0
>>Content-Type: text/plain; format=flowed; charset=us-ascii
>>Content-Transfer-Encoding: 7bit
>>Sender: jik...@ww...
>>List-Archive: <http://www-124.ibm.com/pipermail/jikes-dev/>
>>Date: Sat, 15 Feb 2003 11:18:01 -0700
>>Status: ORr
>>
>>Archie Cobbs wrote:
>>
>>>>So are you saying: the classfiles that jikes generates are exactly
>>>>the same - except for the major/minor version number - no matter
>>>>what -target flag is given? (If not, can you be specific about what
>>>>the differences are?) Is this also true for Sun's javac?
>>>
>>>To answer my own question: it appears to me from looking at the source
>>>that the only differences in the classfile is synthetic code generated
>>>to handle "Foo.class", e.g., using exception chaining.
>>>
>>>So the -target flag (so far) only "targets" the version of the base
>>>Java classes, rather than the virtual machine.
>>>
>>>Let me know if I've gotten myself confused :-)
>>
>>Read the source code in src/bytecode.cpp to see the different code 
>>sequences that jikes outputs depending on the -target option (search for 
>>control.option.target).  For example, this code is different in 1.3 and 1.4:
>>
>>class A {
>>   void m(final int i) {
>>     class B {
>>       int j = i;
>>     }
>>   }
>>}
>>
>>In 1.3, Sun's VM violated the JVMS, and didn't permit the initialization 
>>of instance variables before calling the superconstructor.  Therefore, 
>>compiling with -target 1.3 will issue a constructor that looks like this 
>>(this.this$0 and this.val$i are synthetic variables necessary to make 
>>the local class work correctly):
>>
>>A$1B(A this$0, int val$i) {
>>   super();
>>   this.this$0 = this$0;
>>   this.val$i = val$i;
>>   j = this.val$i;
>>}
>>
>>However, this is semantically incorrect, as setting the this$0 variable 
>>after the superconstructor can cause spurious NullPointerExceptions.
>>
>>In their 1.4 release, Sun corrected their bug and now obey the JLS. 
>>Therefore, compiling with -target 1.4 will issue a constructor like this 
>>(although this is not valid Java, it is valid in the VM):
>>
>>A$1B(A this$0, int val$i) {
>>   this.this$0 = this$0;
>>   this.val$i = val$i;
>>   super();
>>   j = this.val$i;
>>}
>>
>>There are several other changes in emitted code, conditional on the 
>>-target flag.
>>
>>-- 
>>This signature intentionally left boring.
>>
>>Eric Blake             eb...@em...
>>   BYU student, free software programmer
>>
>>----
>>To leave the Jikes-dev mailing list send a message to
>>Jik...@ww... with the word
>>unsubscribe in the body. For more subscription management:
>>http://www-124.ibm.com/developerworks/oss/mailman/listinfo/jikes-dev
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer
> 
> .
> 

-- 
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/