[dev-process] Coding Style Guide
I've just had a look at some C code from jchevm and BootJVM to compare the coding style of both contributions. Both use coding styles which are quite common for C source code but they are slightly different, and I don't think that's good. We should really define a coding style guide before even more code is contributed. I'm not worried about Java code we write, because I assume everyone agrees to use the Java Coding Conventions from Sun [1] here. Much of the development in Harmony is done in C at the moment, and we need a coding style guide here too. I once suggested to use the Java Coding Conventions in C and C++ code too [2] (at least where possible, and we'd have to extend them to cover pre-processor directives and other C/C++ specific things). We could also use a style like Archie Cobbs or Dan Lydick used in their contributions, but IMHO we should write it down and then stick to it. Mark Wielaard provided a link to the project policy of GNU Classpath [3], I guess we could get some Ideas from this too. Regards, David [1] http://java.sun.com/docs/codeconv/ [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200510.mbox/[EMAIL PROTECTED] -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? Umm, I think so Big Brainy Fish Face Stove Pipe Wiggle Room Eileen. But if you get a long little doggie, wouldn't you just call it a dachshund? smime.p7s Description: S/MIME cryptographic signature
Re: Small problems building under cygwin
Dan, To generate a binary that doesn't depend on cygwin shared lib, for that I use the following combination of flags -mno-cygwin -Wl,--add-stdcall-alias, the first one is pretty obvious, the second is result of google'ing for a working solution, as I could not make it work without this flag. I'll look in my cygwin instalation for the header you mentioned. One thing I'm sure is that if we use C++, mixing compilers on the same platform is a huge can of worms. There is not C++ ABI for windows and on linux there are allways some corner cases. On 10/20/05, Apache Harmony Bootstrap JVM [EMAIL PROTECTED] wrote: Rodrigo, An eloquent expression of the sentiments of many experienced developers! I selected GCC just for this reason, it is ubiquitously used on many platforms. Can we use code compiled with CygWin's GCC compiler on a native Windows platform? I've done Win32 apps with GCC and MSVC both, but I've not tried a mix and match between CygWin and Windows with MSVC and GCC. Comments? Anyone else have some experience with this issue? I still think we should see what everyone thinks about MSVC in particular. Dan Lydick -Original Message- From: Rodrigo Kumpera [EMAIL PROTECTED] Sent: Oct 20, 2005 12:40 PM To: harmony-dev@incubator.apache.org Subject: Re: Small problems building under cygwin Dan, Suporting multiple SO and hardware configurations is going to be PITA, adding compiler to this mix might be overkill. It's true that many specialized compiler generate better code than gcc for their platform, f.e. ICC, but does that justify the extra effort? I mean, there are a LOT of stuff we'll need to support many compilers: libraries have diferent performance problems and bugs; compilers have diferent extensions, standards compliance, assembly sintax and bugs. Assembly, for one, is going to be a big issue if we start using native threads and need to use memory barriers, we will have the exact same x86 code in att and intel styles. It's doable, but will require a LOT of effort to be done. Anyway, I don't see much harm in requiring non-linux developers to have instaled the gcc toolchain and a bourne shell interpreter, that's a lot less than many complex projects require for the build enviroment. But even then, I'm biased on this subject, as I cannot survive a windows machine without cygwin and don't care much for anything else but linux. Have said that, I think having build.sh converted to a .bat script is not necessary, only maybe as a subset, that supports only win32/64 on MSVC. On 10/20/05, Apache Harmony Bootstrap JVM [EMAIL PROTECTED] wrote: Rodrigo, Thanks for your help with these items. I think that it should be a simple matter to have 'config.sh' set a 'win32' path. In fact, there should probably be a map function for that include path so that each configuration can set that subdirectory name to whatever Sun declares it to be for that platform instead of depending on the OS platform name. The '__int64' issue is an interesting one! That's why we're trying out all these porting things. To me, the solution depends partly on a matter of build policy, namely, which compilers do we use? I think that there is a case to be made for supporting MSVC in addition to GCC since it has a large installed base, and a Windows version of the build scripts should be able to support both. I suggest that we could have the compiler as one of the configuration options in 'config.sh' for Windows and CygWin, also for the Windows .BAT file equivalent. What do you think? Dan Lydick -Original Message- From: Rodrigo Kumpera [EMAIL PROTECTED] Sent: Oct 19, 2005 5:42 PM To: harmony-dev harmony-dev@incubator.apache.org Subject: Small problems building under cygwin I've found a small issue while building under cygwin. I'm using j2sdk 1.4 and gcc 3.4.4 (cygwin). The problems are when building the jni stuff. First it included on gcc find patch j2sdk\include\cygwin, but it should be j2sdk\include\win32. Second is when building the included file jni_md.h breaks everything as it defines jlong as __int64 and not long long. Fixing both is pretty easy, either edit config/config_opts_always.gcc or rename the directory from win32 to cygwin. The second you can either edit jni_md.h and change __int64 to long long or include a define directive, or something like this, in config/config_opts_always.gcc. I'm not sure what would be the best way to fix this on build.sh, as the first issue is related to build enviroment and the second about incompatible compilers (__int64 works on MSVC and ICC but not gcc) []s Rodrigo Dan Lydick Dan Lydick
Re: Small problems building under cygwin
I'd like to be sure that we don't have a barrier to entry by having to go get commercial software to build the project - by this I mean a MSVC requirement. I'm happy if windows users can use MSVC if they want - i.e. if someone supports it - but it can't be the only option. geir On Oct 20, 2005, at 6:40 PM, Rodrigo Kumpera wrote: Dan, Suporting multiple SO and hardware configurations is going to be PITA, adding compiler to this mix might be overkill. It's true that many specialized compiler generate better code than gcc for their platform, f.e. ICC, but does that justify the extra effort? I mean, there are a LOT of stuff we'll need to support many compilers: libraries have diferent performance problems and bugs; compilers have diferent extensions, standards compliance, assembly sintax and bugs. Assembly, for one, is going to be a big issue if we start using native threads and need to use memory barriers, we will have the exact same x86 code in att and intel styles. It's doable, but will require a LOT of effort to be done. Anyway, I don't see much harm in requiring non-linux developers to have instaled the gcc toolchain and a bourne shell interpreter, that's a lot less than many complex projects require for the build enviroment. But even then, I'm biased on this subject, as I cannot survive a windows machine without cygwin and don't care much for anything else but linux. Have said that, I think having build.sh converted to a .bat script is not necessary, only maybe as a subset, that supports only win32/64 on MSVC. On 10/20/05, Apache Harmony Bootstrap JVM [EMAIL PROTECTED] wrote: Rodrigo, Thanks for your help with these items. I think that it should be a simple matter to have 'config.sh' set a 'win32' path. In fact, there should probably be a map function for that include path so that each configuration can set that subdirectory name to whatever Sun declares it to be for that platform instead of depending on the OS platform name. The '__int64' issue is an interesting one! That's why we're trying out all these porting things. To me, the solution depends partly on a matter of build policy, namely, which compilers do we use? I think that there is a case to be made for supporting MSVC in addition to GCC since it has a large installed base, and a Windows version of the build scripts should be able to support both. I suggest that we could have the compiler as one of the configuration options in 'config.sh' for Windows and CygWin, also for the Windows .BAT file equivalent. What do you think? Dan Lydick -Original Message- From: Rodrigo Kumpera [EMAIL PROTECTED] Sent: Oct 19, 2005 5:42 PM To: harmony-dev harmony-dev@incubator.apache.org Subject: Small problems building under cygwin I've found a small issue while building under cygwin. I'm using j2sdk 1.4 and gcc 3.4.4 (cygwin). The problems are when building the jni stuff. First it included on gcc find patch j2sdk\include\cygwin, but it should be j2sdk\include\win32. Second is when building the included file jni_md.h breaks everything as it defines jlong as __int64 and not long long. Fixing both is pretty easy, either edit config/config_opts_always.gcc or rename the directory from win32 to cygwin. The second you can either edit jni_md.h and change __int64 to long long or include a define directive, or something like this, in config/config_opts_always.gcc. I'm not sure what would be the best way to fix this on build.sh, as the first issue is related to build enviroment and the second about incompatible compilers (__int64 works on MSVC and ICC but not gcc) []s Rodrigo Dan Lydick -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Small problems building under cygwin
I believe Express versions are available for download - http://lab.msdn.microsoft.com/express/visualc/default.aspx -- dims On 10/21/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I'd like to be sure that we don't have a barrier to entry by having to go get commercial software to build the project - by this I mean a MSVC requirement. I'm happy if windows users can use MSVC if they want - i.e. if someone supports it - but it can't be the only option. geir On Oct 20, 2005, at 6:40 PM, Rodrigo Kumpera wrote: Dan, Suporting multiple SO and hardware configurations is going to be PITA, adding compiler to this mix might be overkill. It's true that many specialized compiler generate better code than gcc for their platform, f.e. ICC, but does that justify the extra effort? I mean, there are a LOT of stuff we'll need to support many compilers: libraries have diferent performance problems and bugs; compilers have diferent extensions, standards compliance, assembly sintax and bugs. Assembly, for one, is going to be a big issue if we start using native threads and need to use memory barriers, we will have the exact same x86 code in att and intel styles. It's doable, but will require a LOT of effort to be done. Anyway, I don't see much harm in requiring non-linux developers to have instaled the gcc toolchain and a bourne shell interpreter, that's a lot less than many complex projects require for the build enviroment. But even then, I'm biased on this subject, as I cannot survive a windows machine without cygwin and don't care much for anything else but linux. Have said that, I think having build.sh converted to a .bat script is not necessary, only maybe as a subset, that supports only win32/64 on MSVC. On 10/20/05, Apache Harmony Bootstrap JVM [EMAIL PROTECTED] wrote: Rodrigo, Thanks for your help with these items. I think that it should be a simple matter to have 'config.sh' set a 'win32' path. In fact, there should probably be a map function for that include path so that each configuration can set that subdirectory name to whatever Sun declares it to be for that platform instead of depending on the OS platform name. The '__int64' issue is an interesting one! That's why we're trying out all these porting things. To me, the solution depends partly on a matter of build policy, namely, which compilers do we use? I think that there is a case to be made for supporting MSVC in addition to GCC since it has a large installed base, and a Windows version of the build scripts should be able to support both. I suggest that we could have the compiler as one of the configuration options in 'config.sh' for Windows and CygWin, also for the Windows .BAT file equivalent. What do you think? Dan Lydick -Original Message- From: Rodrigo Kumpera [EMAIL PROTECTED] Sent: Oct 19, 2005 5:42 PM To: harmony-dev harmony-dev@incubator.apache.org Subject: Small problems building under cygwin I've found a small issue while building under cygwin. I'm using j2sdk 1.4 and gcc 3.4.4 (cygwin). The problems are when building the jni stuff. First it included on gcc find patch j2sdk\include\cygwin, but it should be j2sdk\include\win32. Second is when building the included file jni_md.h breaks everything as it defines jlong as __int64 and not long long. Fixing both is pretty easy, either edit config/config_opts_always.gcc or rename the directory from win32 to cygwin. The second you can either edit jni_md.h and change __int64 to long long or include a define directive, or something like this, in config/config_opts_always.gcc. I'm not sure what would be the best way to fix this on build.sh, as the first issue is related to build enviroment and the second about incompatible compilers (__int64 works on MSVC and ICC but not gcc) []s Rodrigo Dan Lydick -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Davanum Srinivas : http://wso2.com/blogs/
Re: [bootvm] Build (was Re: Build problem on Linux)
All: --- Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Oct 20, 2005, at 11:20 PM, Robin Garner wrote: By the way, the top level config.sh/build.sh seems to expect that . is in the path. And any chance of getting this to build using a real build tool ? Make ? Ant ? (or is ant only for java ?) I'd be happy with either make or ant. It would be nice to see at least what it might look like in ant... Someone can propose to switch if we had an example of how it would work hint :) I'm pretty dumb with C having never had any _practical_ experience with it. But I orchestrated some fairly sophisticated COBOL Ant builds with which I was very happy. http://ant-contrib.sourceforge.net hosts some Ant extras including a C compilation task which has a pretty good reputation in the Ant community, if any of you wanted to check that out. br, Matt (Ant PMC) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: Small problems building under cygwin
Dalibor, I'd like to see what you could recommend. I concentrated on getting the source going with minimal infrastructure and with the anticipation of adding this kind of support. Please check out the latest bootJVM source and tinker with it. I'd like to see what you come up with. Dan Lydick -Original Message- From: Dalibor Topic [EMAIL PROTECTED] Sent: Oct 21, 2005 11:38 AM To: harmony-dev@incubator.apache.org Subject: Re: Small problems building under cygwin On Fri, Oct 21, 2005 at 01:08:34PM -0200, Rodrigo Kumpera wrote: Dan, To generate a binary that doesn't depend on cygwin shared lib, for that I use the following combination of flags -mno-cygwin -Wl,--add-stdcall-alias, the first one is pretty obvious, the second is result of google'ing for a working solution, as I could not make it work without this flag. Is there something that speaks against using autotools for all that? I've written autotools setups that work with gcc, MSVC, etc, across CygWin, OS X, various Unix variants, GNU/Linux, etc, and found the underlying tools to have evolved nicely for that in the last few years, offer some pretty neat features (cross-compiling for windows from GNU/Linux for example), and most importantly, take care of the whole platform specific linker flag zoo accross all sorts of operating system and toolchain combinations. cheers, dalibor topic Dan Lydick
Re: Small problems building under cygwin
Dan == Apache Harmony Bootstrap JVM [EMAIL PROTECTED] writes: Dan Another thought about the '__int64' issue. A friend told Dan me a while back that this symbol was typedef'ed in a Dan header file called 'stdint.h' on GCC, but this does not Dan exist on my Solaris box, and I didn't need it anyway. Dan For Linux, I suspect that if you go find this symbol in Dan the /usr/include tree, that it will probably appear in Dan this file (I _think_ this is the correct name, but I am Dan not sure). Perhaps this is the way to solve the problem Dan compiling the JNI code? Harmony is going to have to ship its own jni.h anyway. This is part of a complete JVM. FWIW there's already one in Classpath. The jni_md.h part is typically architecture, OS, and compiler dependent. That said, maintaining this file is not a big deal. The actual code in the x86 linux version of the file in Classpath amounts to 13 lines. Tom
Re: Some questions about the architecture
On 10/21/05, Apache Harmony Bootstrap JVM [EMAIL PROTECTED] wrote:
Comments below.
-Original Message-
From: Rodrigo Kumpera [EMAIL PROTECTED]
Sent: Oct 20, 2005 1:49 PM
To: harmony-dev@incubator.apache.org
Subject: Re: Some questions about the architecture
...snip...
By IP I mean Intruction Pointer, the EIP register in x86 f.e. What I
mean was something like this:
void throw_exception(jobject_t *ex) {
long * ip = (*(ex - 1)); //the return address is after the
arguments
long * sp = (*(ex - 2)); //the old frame pointer is after the
return address
jclass_t * cl = ex-vtable-class_obj;
printf(obj 0x%x ip 0x%x sp 0x%x\n, obj, ip, sp);
printf(--\n);
//this code performs stack unwinding, it misses synchronized
methods .
while(isNotThreadBaseFunction(ip)) {
printf(trace element ip 0x%x sp 0x%x\n, ip, sp);
catch_info_t * info = find_catch_info(ip, cl);
if(info) restore_to(ip, sp, ex, info);
ip = (long *)*(sp+ 1);
sp = (long *)*sp;
}
printf(-\n);
fflush(stdout);
//uncaught exception, must never happen, this is a JVM bug.
//in my vm, at least, uncaught exceptions where handled by the
implementation of Thread.
}
find_catch_info was implemented in java, but looks something like this
(don't bother with the linear search for now):
catch_info * find_catch_info(long *ip, jclass_t *ex) {
if(ip vm -compiledMethodsStart || ip vm-compiledMethodsEnd)
return 0;
foreach(compiled_method_t * m, vm-compiledMethods)
if(m-owns(ip)) //this instruction pointer belongs to this method
return m-findCatch(ip, ex); //find a catch block for the exception
return 0;
}
restore_to is implemented this way:
state void restore_to(long *ip, long *frame, jobject_t *ex, catch_info
*info) {
asm(movl %0, %%eax;
movl %1, %%ebx;
movl %2, %%ecx;
movl %3, %%edx;
movl %%ebx, %%ebp;
movl %%ebp, %%esp;
subl %%edx, %%esp;
pushl %%ecx;
pushl %%eax;
ret;
:
:m(ip), m(frame), m(ex), m(info-stackDelta)
//stackDelta is local storage + temp storage
:%eax, %ebx, %ecx, %edx);
}
This stuff works only in a JIT only enviroment, but only some minor
tweaks would be required to work in a hybrid enviroment
---
Thanks for your clarification on the term 'IP address'. Back to your
question:
It does, but by stack walking I meant not returning null, but having
the code analise the call stack for a proper IP address to use.
In this implementation, unprotected exceptions are handled in
'jvm/src/opcode.c' by references to thread_throw_exception()
in 'jvm/src/thread.c'. Stack printing is available through the
various utilities (esp. jvmutil_print_stack_common())
in 'jvm/src/jvmutil.c'. Protected exceptions are handled by the
exception list found in the 'jvm_pc' field 'excpatridx'. When an
exception is found, this list is queried (by the ATHROW opcode,
which will be available with 0.0.2) and, if found, JVM thread control
is transferred to that handler. If it is _not_ found,
thread_throw_exception()
is called and the thread dies at the end of opcode_run(). This
functionality
looks very similar to your code shown above.
---
...snip...
Dan Lydick
Dan Lydick
Dan,
I'm confused by all this classification on types of exceptions (from
the code you make a distiction from caugth/uncaugth and
Exception/Error/Throwable). My view is that these are not an issue for
the runtime besides the verifier.
We could have the following code on java.lang.Thread:
private void doRun() {
try {
if(runnable != null)
runnable.run();
else
this.run();
} catch(Throwable t) {
this.threadGroup.uncaughtException(t);
}
terminate();
}
The runtime would only assert that the exception have not fallen out
and not care about how it would be handled.
---
I agree that the verifier should look into this, but what happens if
you get a divide by zero error? Or a null pointer exception? These
are not available to the verifier, but are runtime conditions that
do not arise in advance. Therefore, they need to be checked at
run time and exceptions thrown. These two examples are subclasses
to java.lang.RuntimeException and may be thrown at any time.
There are no diferences from the exception handling (define the catch
of an exception) perspective between explicit thrown exceptions (no
matter the Throwable subclass) and runtime generated ones (CCE, NPE,
etc). The only diferences are on the verifier (verify
Re: Some questions about the architecture
Dan == Apache Harmony Bootstrap JVM [EMAIL PROTECTED] writes:
Dan I agree that the verifier should look into this, but what happens if
Dan you get a divide by zero error? Or a null pointer exception? These
Dan are not available to the verifier, but are runtime conditions that
Dan do not arise in advance.
The bytecode verifier doesn't need to know about exceptions at all.
Checked exceptions are purely a language thing. They are not
checked by the runtime.
Dan Therefore, they need to be checked at
Dan run time and exceptions thrown.
True.
Dan One question that I have is that in 'jvm/src/opcode.c' there are
Dan a number of references to thread_throw_exception(). The first
Dan parameter is the type of event, either a java.lang.Error or a
Dan java.lang.Exception or a java.lang.Throwable. Can I get by
Dan without java.lang.Throwable?
I read through the exception code a bit. From my reading, I see a few
flaws.
First, there is no need to differentiate between throwable, exception,
and error in the JVM. 'athrow' merely throws an object whose type is
a subclass of Throwable. The catch handlers do the type comparison at
runtime to see if they should run.
It isn't clear to me how THREAD_STATUS_THREW_UNCAUGHT is ever set.
But, it doesn't matter, since I think this isn't needed. Instead it
is more typical to set up a base frame in the thread which essentially
looks like this:
try {
.. run the thread's code
} catch (Throwable) { // this catches any uncaught exception
.. forward to ThreadGroup
}
I.E, you don't need a special flag.
In thread.h it looks as though the exception being thrown is thrown by
class name:
rchar *pThrowableEvent; /** Exception, Error, or Throwable
* that was thrown by this thread.
* @link #rnull [EMAIL PROTECTED]
* if nothing was thrown.
*/
Typically it is simpler to unify the exception handling code so that
internally generated exceptions (e.g., an NPE) are thrown using the
same mechanism as user-code-generated exceptions. In other words, I
think you're going to want an object reference here.
Tom
Re: Small problems building under cygwin
Dalibor, If autotools have really evolved since last time I checked, start of 2005, then are a really good alternative. They can do some really good magic with platform incompatibility issues. My experience with developing with then is really depressing, I need to have a dozen versions of autoconf instaled because all of then are bloody incompatible and every project require an unique version. Debuging autoconf script are really hard (maybe I'm missing something). Every time I had to generate Makefile.in or Makefile I had a long session of fixing small problems and googleing for solutions. Maybe that's because I do suck when using and developing with autotools and I hope so. Anyway, configure scripts are really sweet... when they work and don't screw up too badly. On 10/21/05, Dalibor Topic [EMAIL PROTECTED] wrote: On Fri, Oct 21, 2005 at 01:08:34PM -0200, Rodrigo Kumpera wrote: Dan, To generate a binary that doesn't depend on cygwin shared lib, for that I use the following combination of flags -mno-cygwin -Wl,--add-stdcall-alias, the first one is pretty obvious, the second is result of google'ing for a working solution, as I could not make it work without this flag. Is there something that speaks against using autotools for all that? I've written autotools setups that work with gcc, MSVC, etc, across CygWin, OS X, various Unix variants, GNU/Linux, etc, and found the underlying tools to have evolved nicely for that in the last few years, offer some pretty neat features (cross-compiling for windows from GNU/Linux for example), and most importantly, take care of the whole platform specific linker flag zoo accross all sorts of operating system and toolchain combinations. cheers, dalibor topic
Re: Some questions about the architecture
On 10/21/05, Tom Tromey [EMAIL PROTECTED] wrote:
Dan == Apache Harmony Bootstrap JVM [EMAIL PROTECTED] writes:
Dan I agree that the verifier should look into this, but what happens if
Dan you get a divide by zero error? Or a null pointer exception? These
Dan are not available to the verifier, but are runtime conditions that
Dan do not arise in advance.
The bytecode verifier doesn't need to know about exceptions at all.
Checked exceptions are purely a language thing. They are not
checked by the runtime.
Dan Therefore, they need to be checked at
Dan run time and exceptions thrown.
True.
Dan One question that I have is that in 'jvm/src/opcode.c' there are
Dan a number of references to thread_throw_exception(). The first
Dan parameter is the type of event, either a java.lang.Error or a
Dan java.lang.Exception or a java.lang.Throwable. Can I get by
Dan without java.lang.Throwable?
I read through the exception code a bit. From my reading, I see a few
flaws.
First, there is no need to differentiate between throwable, exception,
and error in the JVM. 'athrow' merely throws an object whose type is
a subclass of Throwable. The catch handlers do the type comparison at
runtime to see if they should run.
It isn't clear to me how THREAD_STATUS_THREW_UNCAUGHT is ever set.
But, it doesn't matter, since I think this isn't needed. Instead it
is more typical to set up a base frame in the thread which essentially
looks like this:
try {
.. run the thread's code
} catch (Throwable) { // this catches any uncaught exception
.. forward to ThreadGroup
}
I.E, you don't need a special flag.
In thread.h it looks as though the exception being thrown is thrown by
class name:
rchar *pThrowableEvent; /** Exception, Error, or Throwable
* that was thrown by this thread.
* @link #rnull [EMAIL PROTECTED]
* if nothing was thrown.
*/
Typically it is simpler to unify the exception handling code so that
internally generated exceptions (e.g., an NPE) are thrown using the
same mechanism as user-code-generated exceptions. In other words, I
think you're going to want an object reference here.
Tom
I think unless the vm extract the class name of the exception before
stack unwinding, it's required. One can, for example, throw an
exception using reflection:
throw (Throwable)Class.forName(java.lang.Exception).newInstance();
Re: Small problems building under cygwin
Tom, You hit the nail on the head. Harmony _will_ need to ship a jni.h at some point, including platform-specific extensions, or arrange with somebody like GNU Classpath to provide it. But for now, part of what I am trying to accomplish is a way for people to _not_ depend on any particular JDK at this early stage of the project. This is a result of lurking on the dev@ list for the first couple of months of the project. I saw much discussion about class libraries and their relative merits and thought it would be wise to stick my head in the sand until the pain got too intense and I had to deal with the issue. :-) In other words, let people use their existing JDK's for the time being (especially for the compiler and for the JAR utility, perhaps basic core classes like java.lang.Object), we'll solve the problem in the form it comes to us when we have a code base to deal with. Now, I don't know if we are yet to that point because I need to get all the opcodes working, but if someone knows of an opcode test suite, that would _definitely_ advance the quality of the software and get us closer to that milestone of needing our own jni.h file(s). Dan Lydick -Original Message- From: Tom Tromey [EMAIL PROTECTED] Sent: Oct 21, 2005 11:45 AM To: harmony-dev@incubator.apache.org, Apache Harmony Bootstrap JVM [EMAIL PROTECTED] Subject: Re: Small problems building under cygwin Dan == Apache Harmony Bootstrap JVM [EMAIL PROTECTED] writes: Dan Another thought about the '__int64' issue. A friend told Dan me a while back that this symbol was typedef'ed in a Dan header file called 'stdint.h' on GCC, but this does not Dan exist on my Solaris box, and I didn't need it anyway. Dan For Linux, I suspect that if you go find this symbol in Dan the /usr/include tree, that it will probably appear in Dan this file (I _think_ this is the correct name, but I am Dan not sure). Perhaps this is the way to solve the problem Dan compiling the JNI code? Harmony is going to have to ship its own jni.h anyway. This is part of a complete JVM. FWIW there's already one in Classpath. The jni_md.h part is typically architecture, OS, and compiler dependent. That said, maintaining this file is not a big deal. The actual code in the x86 linux version of the file in Classpath amounts to 13 lines. Tom Dan Lydick
Compilers and configuration tools
I'm with Geir on his comments, but evaluating MSVC I think is a good idea because there are so many folks who use it-- or is it? Rodrigo' comments about confusion with multiple compiler support make a compelling argument about going with _one_ compiler-- and look at the minor diffs we have already experienced! Rodrigo needs '__int64' on hit Linux box, and Robin is arguing with finding the correct 'thread.h' (apparently), and I had no problems. All of us are using GCC. What does this tell us? The less we deal with mechanical issues like compiler invocations, the more real work we get done. Bottom line: Should we just declare one compiler for now and branch out later, once we have all of our porting done? Next observation: There has been an offer of help with 'autotools' and some concern about that tool. I've seen GNU autoconf work (part of autotools?) nicely, and I'm interested in exploring this avenue further. Dan Lydick -Original Message- From: Davanum Srinivas [EMAIL PROTECTED] Sent: Oct 21, 2005 10:31 AM To: harmony-dev@incubator.apache.org Subject: Re: Small problems building under cygwin I believe Express versions are available for download - http://lab.msdn.microsoft.com/express/visualc/default.aspx -- dims On 10/21/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: I'd like to be sure that we don't have a barrier to entry by having to go get commercial software to build the project - by this I mean a MSVC requirement. I'm happy if windows users can use MSVC if they want - i.e. if someone supports it - but it can't be the only option. geir ...snip... Dan Lydick
Re: Some questions about the architecture
-Original Message- From: Rodrigo Kumpera [EMAIL PROTECTED] Sent: Oct 21, 2005 12:08 PM To: harmony-dev@incubator.apache.org Subject: Re: Some questions about the architecture ...snip... I agree that the verifier should look into this, but what happens if you get a divide by zero error? Or a null pointer exception? These are not available to the verifier, but are runtime conditions that do not arise in advance. Therefore, they need to be checked at run time and exceptions thrown. These two examples are subclasses to java.lang.RuntimeException and may be thrown at any time. There are no diferences from the exception handling (define the catch of an exception) perspective between explicit thrown exceptions (no matter the Throwable subclass) and runtime generated ones (CCE, NPE, etc). The only diferences are on the verifier (verify checked exceptions) and how they are trapped (NPE could use the segv signal). I don't understand your (un)protected exception classification. Perhaps I need to use more standard terminology. In place of unprotected, I should say uncaught. (Sorry about that! I'll try to get my terms straight here.) This means an exception without an explicit handler, which could include a java.lang.RuntimeException or a java.lang.Error. The VM spec sections 2.16, 2.16.2, and 2.17.7 discuss uncaught exceptions. This is why I have felt I had to make a distinction and so implement my code. Try taking a look at the JVM specification, section 2.16. I have tried to write my code to implement the functionality described there. I would appreciate you studying section 2.16 and comparing it against my implementation of the exception mechanism to see if you find any flaws in my logic. If so, please let me know what you find. One question that I have is that in 'jvm/src/opcode.c' there are a number of references to thread_throw_exception(). The first parameter is the type of event, either a java.lang.Error or a java.lang.Exception or a java.lang.Throwable. Can I get by without java.lang.Throwable? Everything I throw so far is either an Error or an Exception. I just included Throwable in case I had something else because I think I remember something in the spec about something that is not an Error or an Exception, so I thought I would try to cover all angles. Thanks for your help. Dan Lydick --- Reading 2.16.2 Handling an Exception I could not find any diference between how Exception and Error exceptions are handled. The section only defined how an expression/statement is dynamically enclosed by a catch block. And even then, there are no distinction between explicit throws, runtime generated exceptions and asynchronous exceptions. VM spec section 2.16.4 makes that distinction, but I'm still wondering if I can get by without distinguishing java.lang.Throwable here. Dan Lydick
Re: Questions about GC implementations
Robin, Over the last few days as we have all been discussing heap and GC, I have been growing mroe curious by the hour about what you see as a design critique of the GC hooks I defined. Perhaps I am taking it a bit too simplistically, but all I did was define a GC hook anywhere an object or array reference or a class load or unload happened. How does your concept differ? And what sort of approach should be used instead. GC is a completely new area to me and I am very interested in learning about what could be done. One of these days I'm going to read the standard (Jones?) book on JVM garbage collecition, but not today. Even if you don't have your proposal ready now, I'm still interested in hearing how you approach the foundation of GC design and how you would approach it on this JVM. Dan Lydick -Original Message- From: Robin Garner [EMAIL PROTECTED] Sent: Oct 20, 2005 2:24 PM To: Apache Harmony Bootstrap JVM [EMAIL PROTECTED] Subject: Re: Questions about GC implementations Hi Dan, I'm keeping up with e-mail in between OOPSLA talks right now, so it doesn't give me much time :) I think I understand where the interfaces fit in, and (not to put too fine a point on it) I think they need to be thrown out real quick, and replaced with a unified heap manager interface. I'm sketching out how that needs to work, but it's probably not something that should be done in too much of a hurry. I hope to have some kind of draft to the list tomorrowish. cheers Robin, You asked a number of questions about GC on this JVM recently. Have I answered everything to your satisfaction? I would like to discuss with you the possibilities for writing one or more algorithms. What are your recent thoughts on this subject? Dan Lydick
Re: Small problems building under cygwin
On Fri, Oct 21, 2005 at 10:45:59AM -0600, Tom Tromey wrote: Dan == Apache Harmony Bootstrap JVM [EMAIL PROTECTED] writes: Dan Another thought about the '__int64' issue. A friend told Dan me a while back that this symbol was typedef'ed in a Dan header file called 'stdint.h' on GCC, but this does not Dan exist on my Solaris box, and I didn't need it anyway. Dan For Linux, I suspect that if you go find this symbol in Dan the /usr/include tree, that it will probably appear in Dan this file (I _think_ this is the correct name, but I am Dan not sure). Perhaps this is the way to solve the problem Dan compiling the JNI code? Harmony is going to have to ship its own jni.h anyway. This is part of a complete JVM. FWIW there's already one in Classpath. The jni_md.h part is typically architecture, OS, and compiler dependent. That said, maintaining this file is not a big deal. The actual code in the x86 linux version of the file in Classpath amounts to 13 lines. __int64 is a compiler specific extension, afaik, supported by MSVC++, and I believe gcc defines it also somewhere deep down inside. the portable way to get types of well defined sizes is to use C99's inttypes.h and stdint.h. That's what Kaffe does for jni_md.h, and I really need to get the patch up into GNU classpath before the next release. there is a wrapper autoconf macro for older systems on ac-archive. cheers, dalibor topic Tom
Re: Some questions about the architecture
On 10/21/05, Apache Harmony Bootstrap JVM [EMAIL PROTECTED] wrote: -Original Message- From: Rodrigo Kumpera [EMAIL PROTECTED] Sent: Oct 21, 2005 12:08 PM To: harmony-dev@incubator.apache.org Subject: Re: Some questions about the architecture ...snip... I agree that the verifier should look into this, but what happens if you get a divide by zero error? Or a null pointer exception? These are not available to the verifier, but are runtime conditions that do not arise in advance. Therefore, they need to be checked at run time and exceptions thrown. These two examples are subclasses to java.lang.RuntimeException and may be thrown at any time. There are no diferences from the exception handling (define the catch of an exception) perspective between explicit thrown exceptions (no matter the Throwable subclass) and runtime generated ones (CCE, NPE, etc). The only diferences are on the verifier (verify checked exceptions) and how they are trapped (NPE could use the segv signal). I don't understand your (un)protected exception classification. Perhaps I need to use more standard terminology. In place of unprotected, I should say uncaught. (Sorry about that! I'll try to get my terms straight here.) This means an exception without an explicit handler, which could include a java.lang.RuntimeException or a java.lang.Error. The VM spec sections 2.16, 2.16.2, and 2.17.7 discuss uncaught exceptions. This is why I have felt I had to make a distinction and so implement my code. The thing is, there's no need to make such distinction. What happens when an exception is uncaught is, more or less, the following -The exception is passed to the thread's uncaughtExceptionHandler -The exception is passed to the ThreadGroup's uncaughtException method -The thread is terminated -If this was the last non-daemon thread, terminate the JVM. It's easy to have this stuff implemented in the class library, and not in the runtime, using Java a well smaller code. The class lib just make sure that no thread will ever have an uncaught exception of any possible kind. That's my point, at least. Try taking a look at the JVM specification, section 2.16. I have tried to write my code to implement the functionality described there. I would appreciate you studying section 2.16 and comparing it against my implementation of the exception mechanism to see if you find any flaws in my logic. If so, please let me know what you find. One question that I have is that in 'jvm/src/opcode.c' there are a number of references to thread_throw_exception(). The first parameter is the type of event, either a java.lang.Error or a java.lang.Exception or a java.lang.Throwable. Can I get by without java.lang.Throwable? Everything I throw so far is either an Error or an Exception. I just included Throwable in case I had something else because I think I remember something in the spec about something that is not an Error or an Exception, so I thought I would try to cover all angles. Thanks for your help. Dan Lydick --- Reading 2.16.2 Handling an Exception I could not find any diference between how Exception and Error exceptions are handled. The section only defined how an expression/statement is dynamically enclosed by a catch block. And even then, there are no distinction between explicit throws, runtime generated exceptions and asynchronous exceptions. VM spec section 2.16.4 makes that distinction, but I'm still wondering if I can get by without distinguishing java.lang.Throwable here. Yes, 2.16.4 makes some distinctions, but I cannot see how they are important to the runtime unless for bytecode verification purpoises.
Re: Questions about GC implementations
Robin, Over the last few days as we have all been discussing heap and GC, I have been growing mroe curious by the hour about what you see as a design critique of the GC hooks I defined. Perhaps I am taking it a bit too simplistically, but all I did was define a GC hook anywhere an object or array reference or a class load or unload happened. How does your concept differ? And what sort of approach should be used instead. GC is a completely new area to me and I am very interested in learning about what could be done. One of these days I'm going to read the standard (Jones?) book on JVM garbage collecition, but not today. Even if you don't have your proposal ready now, I'm still interested in hearing how you approach the foundation of GC design and how you would approach it on this JVM. Dan Lydick In the garbage collectors I've worked with, the essential design is: - 'new' allocates space on the heap. - The header of each object contains a pointer (or equiv) to a per-class data structure, that points to the GC map for the object (and virtual dispatch tables etc etc) - Reference fields in objects contain pointers directly to the heap objects they reference. - Pointer loads and stores are (optionally) performed via barriers - the terminology is a little confusing: these are not synchronization barriers, but opportunities for the GC to intercept the load/store and do some additional processing. Write barriers are common, read barriers less so. - There are many styles of collector, but the most common class uses tracing, in which a root set of pointers is used to determine an initial set of live objects, and the collector performs a transitive closure over this set to establish the set of all live objects. The root set is commonly the thread stacks and the static pointer fields. - The above is also complicated by . Reference types . Finalization . Locks . Address-based hashing The solutions to these are all pretty well known, but complicate the design This is pretty much it - the rest (45 years of research) is optimizing the way this is all done. Perhaps I am taking it a bit too simplistically, but all I did was define a GC hook anywhere an object or array reference or a class load or unload happened. How does your concept differ? And what sort of approach should be used instead. This I think brings us back to my initial question, asking what these hooks were supposed to do. I guess you're saying you had a vague idea that the GC might need to know about these events, so put hooks in for them. When I was looking around the code trying to find out where to start hooking in a managed heap, I looked for the 'new' or 'alloc' operation, and couldn't seem to find it. Interface design for memory managers is an interesting research question. Weldon has posted the ORP interface, which I think is probably pretty close to a good design. I would make some additional operations explicit in the interface, and abstract over some of the features that are a 'shared understanding' between GC and VM in the ORP design, but I think a final design would have a lot in common with it. The MMTk interface is the one I know best, and while it isn't perfect in itself, my improvements to the ORP design would probably involve taking features from the MMTk interface and adapting them to the environment. be used instead. GC is a completely new area to me and I am very interested in learning about what could be done. One of these days I'm going to read the standard (Jones?) book on JVM garbage collecition, but not today. Yep - Jones and Lins is the standard reference. If you're looking for a good brief introduction, you could do much worse than the wikipedia entry, which seems to cover most of the important parts. Even if you don't have your proposal ready now, I'm still interested in hearing how you approach the foundation of GC design and how you would approach it on this JVM. I think its important that the initial interface contains all the features that have ramifications for the core design ideas of the rest of the system. Hope to have a draft out next week. cheers, Robin
