Does Jini1.1 work with latest Kaffe?
Hi, May I know if Jini1.1 can work with latest Kaffe? We are getting following exception while running Jini with Kaffe: 'ClassCast Exception' while exporting the RemoteObject. Our implementation class implements the interface which extends the RemoteObject. And in the constructor of the Implementation class , we are exporting the object of this class , so that it can act as a Remote Server i.e a Remote Listener. By using UnicastRemoteObject.exportObject(this); where 'this' is the object of the Implementation class. - "Attitude Matters" Parthasarathy G Technology Development Center - HomeNet Wipro Technologies, E&I 53/1 , Hosur Road, Madiwala Phone: 91-80-5502001-008 x3130 Fax No: 5502160 Bangalore - 560 068. Visit Home Networks Website * Intranet: http://gruha.wipro.com * Internet: http://www.wipro.com/homenet/ **Disclaimer Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited.
Problem: "ksemPut : Assertion 'sem --> count = = 0' failed."
Hi, Problem -- "Kaffe : ksem.h :115 : ksemPut : Assertion 'sem --> count = = 0' failed Aborted" Analysis is -- It is an assertion failure when the count was 1. Which means that when 'ksemGet' times out, still 'ksemPut' is getting called. We are using the following version 1.0.6 of Kaffe (kaffe-snap-20010819). Has anybody encountered this problem. Is there a fix available for it? Regards, Partha - "Attitude Matters" Parthasarathy G Technology Development Center - HomeNet Wipro Technologies, E&I 53/1 , Hosur Road, Madiwala Phone: 91-80-5502001-008 x3130 Fax No: 5502160 Bangalore - 560 068. Visit Home Networks Website * Intranet: http://gruha.wipro.com * Internet: http://www.wipro.com/homenet/ **Disclaimer Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited.
UTF8 error
Hi, Kaffe aborted with the following error Kaffe:utf8const.c:204:utf8Const, Release:Assertion 'utf8 -> nrefs >= 1' failed What is the reason for this error? How to fix it? Regards, Partha - "Attitude Matters" Parthasarathy G Technology Development Center - HomeNet Wipro Technologies, E&I 53/1 , Hosur Road, Madiwala Phone: 91-80-5502001-008 x3130 Fax No: 5502160 Bangalore - 560 068. Visit Home Networks Website * Intranet: http://gruha.wipro.com * Internet: http://www.wipro.com/homenet/ **Disclaimer Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited.
Kaffe CVS: kaffe jim
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: jim 02/04/01 21:57:15 Modified files: test/regression: .cvsignore Log message: Update to ignore ExceptionTest file
Re: Rewriting byte codes
On Tue, Apr 02, 2002 at 02:48:36AM +0200, Artur Biesiadowski wrote: > > Erik Corry wrote: > >>> AFAIK, hotspot stops thread, replaces closest safe points with some trap >>> and let thread run until it hit one. Then it restores original >>> instruction and voila. >> >> >> This sounds pretty ugly to me, since it involves lots of writing >> to the instruction stream with corresponding I-cache flushes etc. > > I think that I-cache flush penalty is neglible compared to cost of > switching threads few times and performing gc. We are talking about > extra 20-50 cycles and gc will take about 1ms minimum (which gives about > 100 cycles). The real cost of an I-cache flush isn't the 20-50 cycles it takes to flush the I-cache, it's the time it takes to refill it again from L2. But it's probably the right tactic anyhow. The alternative is to put checks in at every safe point so you can just set a global instead of having to rewrite code. -- Erik Corry [EMAIL PROTECTED]
Kaffe CVS: kaffe jim
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: jim 02/04/01 21:48:30 Modified files: . : ChangeLog Log message: Oops. Forgot to update changelog
Delaying first release candidate for a few days
Hi, I think I need a few more days before I'm ready to tag "1.0.7 Release Candidate 1". I didn't get to play enough with it yet, and there are a few more patches I want to see go in before freezing it. Hopefully we can freeze it before Friday. Cheers, - Jim
Re: JRE file layout for 1.0.7?
> > Not at all. Also please make sure that the nativedir macro is > DESTDIR-aware. > > I need to test that. I'm not sure if it is or not. I just tested it, and the install seems to respect DESTDIR. Cheers, - Jim
Kaffe CVS: kaffe jim
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: jim 02/04/01 21:19:56 Modified files: . : configure configure.in Log message: Fix alignment check to give more sensible default when cross-compiling, in order to prevent unaligned accesses
Kaffe CVS: kaffe jim
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: jim 02/04/01 20:52:07 Modified files: libraries/javalib: .cvsignore Makefile.am Makefile.in Log message: Remove rt.jar when doing make clean
Kaffe CVS: kaffe jim
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: jim 02/04/01 20:38:17 Modified files: kaffe/scripts : kaffe.in Log message: Fix for /tmp file insecurity when using KAFFE_DEBUG, thanks to Andrew Dalgleish
Re: JRE file layout for 1.0.7?
> Exactly, thank you. And like Sun's JRE, please put Kaffe arch dependent > libraries in kaffe//. ;-) Done. > > Is anybody opposed to this? > > Not at all. Also please make sure that the nativedir macro is DESTDIR-aware. I need to test that. I'm not sure if it is or not. Cheers, - Jim
Re: JRE file layout for 1.0.7?
Okay, I did it. The changes to use a JDK/JRE style file layout are committed in CVS. Here's what the layout looks like after doing "make install". Please test it and give me some feeback. Cheers, - Jim /usr/local/kaffe |-- bin | |-- appletviewer | |-- install-jar | |-- jar | |-- java | |-- javac | |-- javadoc | |-- javakey | |-- javap | |-- jdb | |-- kaffe | |-- kaffeh | |-- kjc | |-- kopi | |-- native2ascii | |-- rmic | |-- rmiregistry | `-- serialver |-- include | |-- jni.h | `-- kaffe | |-- Arrays.h | |-- errors.h | |-- java_lang_Object.h | |-- java_lang_String.h | |-- java_lang_Thread.h | |-- java_lang_ThreadGroup.h | |-- java_lang_Throwable.h | |-- jmalloc.h | |-- jni_cpp.h | |-- jsyscall.h | |-- jtypes.h | `-- native.h |-- jre | |-- bin | | |-- Kaffe | | |-- java | | |-- kaffe | | `-- rmiregistry | `-- lib | |-- comm.jar | |-- i386 | | |-- libio-1.0.6.so | | |-- libio.la | | |-- libio.so -> libio-1.0.6.so | | |-- libkaffevm-1.0.6.so | | |-- libkaffevm.la | | |-- libkaffevm.so -> libkaffevm-1.0.6.so | | |-- libmanagement-1.0.6.so | | |-- libmanagement.la | | |-- libmanagement.so -> libmanagement-1.0.6.so | | |-- libmath-1.0.6.so | | |-- libmath.la | | |-- libmath.so -> libmath-1.0.6.so | | |-- libmicrosoft-1.0.6.so | | |-- libmicrosoft.la | | |-- libmicrosoft.so -> libmicrosoft-1.0.6.so | | |-- libnative-1.0.6.so | | |-- libnative.la | | |-- libnative.so -> libnative-1.0.6.so | | |-- libnet-1.0.6.so | | |-- libnet.la | | |-- libnet.so -> libnet-1.0.6.so | | |-- libsecurity-1.0.6.so | | |-- libsecurity.la | | |-- libsecurity.so -> libsecurity-1.0.6.so | | |-- libzip-1.0.6.so | | |-- libzip.la | | `-- libzip.so -> libzip-1.0.6.so | |-- microsoft.jar | |-- pjava.jar | |-- rmi.jar | |-- rt.jar | |-- security | | `-- java.security | `-- servlet.jar |-- lib | |-- kjc.jar | `-- tools.jar `-- man `-- man1 `-- kaffe.1 11 directories, 71 files
Kaffe CVS: kaffe jim
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: jim 02/04/01 19:15:02 Modified files: . : Makefile.in configure configure.in config : Makefile.in include: Makefile.am Makefile.in kaffe : Makefile.in kaffe/kaffe: Makefile.am Makefile.in kaffe/kaffeh : Makefile.in kaffe/kaffevm : Makefile.am Makefile.in kaffe/kaffevm/gcj: Makefile.in kaffe/kaffevm/intrp: Makefile.in kaffe/kaffevm/jit: Makefile.in kaffe/kaffevm/jit3: Makefile.in kaffe/kaffevm/systems: Makefile.in kaffe/kaffevm/systems/beos-native: Makefile.in kaffe/kaffevm/systems/oskit-pthreads: Makefile.in kaffe/kaffevm/systems/unix-jthreads: Makefile.in kaffe/kaffevm/systems/unix-pthreads: Makefile.in kaffe/man : Makefile.in kaffe/scripts : Makefile.am Makefile.in kaffe.in kaffe/scripts/bat: Makefile.in kaffe/scripts/compat: Makefile.am Makefile.in kaffe/xprof: Makefile.in libraries : Makefile.in libraries/clib : Makefile.in libraries/clib/awt: Makefile.in libraries/clib/awt/X: Makefile.in libraries/clib/io: Makefile.in libraries/clib/management: Makefile.in libraries/clib/math: Makefile.in libraries/clib/native: Makefile.in libraries/clib/net: Makefile.in libraries/clib/security: Makefile.am Makefile.in libraries/clib/zip: Makefile.in libraries/extensions: Makefile.in libraries/extensions/comm: Makefile.in libraries/extensions/comm/javalib: Makefile.am Makefile.in libraries/extensions/microsoft: Makefile.in libraries/extensions/microsoft/clib: Makefile.in libraries/extensions/microsoft/javalib: Makefile.am Makefile.in libraries/extensions/pjava: Makefile.in libraries/extensions/pjava/javalib: Makefile.am Makefile.in libraries/extensions/rmi: Makefile.in libraries/extensions/rmi/javalib: Makefile.am Makefile.in libraries/extensions/servlet: Makefile.in libraries/extensions/servlet/javalib: Makefile.am Makefile.in libraries/extensions/tools: Makefile.in libraries/extensions/tools/javalib: Makefile.am Makefile.in libraries/javalib: Makefile.am Makefile.in test : Makefile.in test/regression: Makefile.in Log message: Initial attempt at doing a JDK/JRE style install (default location is /usr/local/kaffe).
Re: Rewriting byte codes
Erik Corry wrote: >>AFAIK, hotspot stops thread, replaces closest safe points with some trap >>and let thread run until it hit one. Then it restores original >>instruction and voila. > > > This sounds pretty ugly to me, since it involves lots of writing > to the instruction stream with corresponding I-cache flushes etc. I think that I-cache flush penalty is neglible compared to cost of switching threads few times and performing gc. We are talking about extra 20-50 cycles and gc will take about 1ms minimum (which gives about 100 cycles). Artur
patch for include/Makefile.am
The attached patch causes the Make to abort if kaffeh has a problem. Currently an error return from kaffeh is ignored. (I was getting errors because my Klasses.jar was badly corrupted.) I "fixed" the problem by including a 'set -e' in the complex shell sequence that invokes kaffeh. -e should cause the shell to bail on an unchecked error. I'm not sure if this is portable, or if there is an alternative automake/autoconf/libtool approved way of getting this behavior. If someone applies this patch, don't forget to regen Makefile.in, too. -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] If Gates got a dime each time Windows crashed... Oh, nevermind... Index: Makefile.am === RCS file: /cvs/kaffe/kaffe/include/Makefile.am,v retrieving revision 1.25 diff -u -b -r1.25 Makefile.am --- Makefile.am 19 Aug 2001 20:32:47 - 1.25 +++ Makefile.am 2 Apr 2002 00:38:16 - @@ -126,7 +126,7 @@ stamp-h0all: stamp-kaffeh $(KLASSES_JAR) ## Then, generate each header file, ## but if it does not change, do not touch it - @for f in $(DERIVED_HDRS); do \ + @set -e; for f in $(DERIVED_HDRS); do \ class=`echo $$f | sed -e 's%.*/%%g' -e 's%\.h$$%%' -e 's%_%/%g'`; \ echo "$(KAFFEH) -classpath $(KLASSES_JAR) -o $$f $$class"; \ $(KAFFEH) -classpath $(KLASSES_JAR) -o stamp-h0$$f $$class; \ @@ -148,7 +148,7 @@ stamp-h1all: stamp-kaffeh $(KLASSES_JAR) ## Then, generate each header file, ## but if it does not change, do not touch it - @for f in $(JNI_DERIVED_HDRS); do \ + @set -e; for f in $(JNI_DERIVED_HDRS); do \ class=`echo $$f | sed -e 's%.*/%%g' -e 's%\.h$$%%' -e 's%_%/%g'`; \ echo "$(KAFFEH) -jni -classpath $(KLASSES_JAR) -o $$f $$class"; \ $(KAFFEH) -jni -classpath $(KLASSES_JAR) -o stamp-h1$$f $$class; \
Re: java.util.prefs
Hi, On Tue, 2002-04-02 at 00:38, Patrick Tullmann wrote: > Anyone know of open-source implementations of the new java.util.prefs > API that could be used with (or incorporated into) Kaffe? I wrote one last year for GNU Classpath, it can be found in CVS or I can send you the source files. It is based on a beta version of the API though. And I have currently no time to work on it. http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/prefs/ > I haven't the time to do it from scratch, but could do some work to > integrate it into Kaffe. > > If anyone's looking for a medium-size project to do, the > java.util.prefs API is nicely documented, and fairly well contained > (except for the bit about XML exports). The bit about XML exports is precisely the part that is not implemented yet :) I have CCed Mark Anderson who has recently tried to use the package in his own project. I can also forward his remarks about the current implementation and the bugs he found. Cheers, Mark
Re: java.util.prefs
I wonder what the gnu classpath project has for java.util.prefs (or the gcj folks for that matter). Marcus Smith On Mon, 2002-04-01 at 15:38, Patrick Tullmann wrote: > > Anyone know of open-source implementations of the new java.util.prefs > API that could be used with (or incorporated into) Kaffe? > > I haven't the time to do it from scratch, but could do some work to > integrate it into Kaffe. > > If anyone's looking for a medium-size project to do, the > java.util.prefs API is nicely documented, and fairly well contained > (except for the bit about XML exports). > > -Pat > > - - --- --- -- -- - - - > Pat Tullmann [EMAIL PROTECTED] > To understand recursion one must first understand recursion.
java.util.prefs
Anyone know of open-source implementations of the new java.util.prefs API that could be used with (or incorporated into) Kaffe? I haven't the time to do it from scratch, but could do some work to integrate it into Kaffe. If anyone's looking for a medium-size project to do, the java.util.prefs API is nicely documented, and fairly well contained (except for the bit about XML exports). -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] To understand recursion one must first understand recursion.
Re: Rewriting the GC
On Mon, Apr 01, 2002 at 11:10:18AM -0700, Patrick Tullmann wrote:
> Erik wrote:
> > > The big problem with walking the stack isn't the Java stack as much as
> > > the native stack. You could walk the Java parts precisely, and the
> > > native bits conservatively, but I don't know what you'd win anything
> > > by doing this.
> >
> > OK, I'm not so familiar with the way Java interacts with
> > native code, but why do we need to walk the native bits at
> > all? Surely C code doesn't need GC?
>
> All the native methods in Kaffe, the threading system, the core class
> loading --- that's all written in C. That code uses the same stack as
> the Java code. That code uses Java object refereneces left and right,
> and stores them on the stack.
Ah, now I understand.
Well, I'm not going to do the work here, so perhaps I should just
shut up, but one way to do this is to have a (per-thread) global
called gc_chain that is available in every function. Then when
you want to have gc-able structures on the stack you do something
like
struct thingie {
gcChain *next;
int signature;
here go the real fields
}
Then you use it with
{
struct thingie t;
t->next = gc_chain;
t->signature = THINGIESIGNATURE;
memzero(the rest of t);
gc_chain = (gcChain *)&t;
Now do stuff with t
}
the GC has a chain of structures on the stack, each with a
signature that tells it what types are in it. You can have
signature called 1reference, 2references, 3references etc.
to allow you to save single pointer (not structs) on the
stack too.
For this to work you can't allow GC at random points in the
code (since things could be in registers), but every so often
(ie back edges etc.) the C code has to call checkgc(gc_chain)
(the parameter will ensure that all registers are flushed to
memory) which will check whether the other threads are waiting
to do a GC. The gc_chain should also be a parameter to the
allocation routine so we can always do a GC in there.
I guess we have to have the ability to walk forward to the
next safe point, and since that's the same as what we need
in Java code I guess that's the way to do it.
I haven't thought through all details of this idea, but it
seems to me it should work.
> > > As I understand GC trade-offs, the big win for precise GC is the
> > > ability to update pointers and thus implement a compacting collector.
> > > Is there something else you're hoping to get out of precise stack
> > > walking?
> >
> > Predictability and speed of GC.
>
> You're talking about bogus pointer references in a conservative scan
> being viewed as pointers, when in fact they're just integers that look
> like pointers?
Actually, I was just talking about compacting/generational/semispace
GCs, which require the ability to move objects, and which are all
faster than nonmoving GCs because they only treat a small part
of the heap on any given GC.
> nice ones) a system that supports safe points is (and I'm somewhat
> guessing here) much easier to write safe native code in --- you don't
> have to worry about your C code getting interrupted by the GC at
> arbitrary points, only at safe points you explicitly insert in your
> code. There are downsides, of course --- like if you forget to put a
> safe point in somewhere, the GC can be blocked for a long time.
I agree now.
--
Erik Corry [EMAIL PROTECTED]
Re: Rewriting byte codes
On Mon, Apr 01, 2002 at 01:05:50PM +0200, Artur Biesiadowski wrote: > > Erik Corry wrote: > > > There's a lot to be said for this, but since you can allocate > > unlimited memory in an exception handler, every point that can > > throw an exception has to be a safe point [...] > > If exception is thrown, you don't care about registers (unless you > write-cache locals in registers, Good point, but you still have the problems with a thread that has been suspended by the OS at a random point (if you use OS threads, which you have to if you want to benefit from SMP). > but it will give problems even without > precise gc), Why? Not that x86 has enough registers, but it might be interesting for RISC. I think Hotspot allocates registers freely to both stack and local variables. > You also need to mark which local variables are live and which are > dead - because if you will use dead object pointers as live, you are > non-precise and possibly unstable (as it can point inside some newly > allocated object). As far as I can see it can only be _either_ non-precise _or_ unstable. It could be nonprecise in the sense that you might not free some memory as soon as you could have (but not in the sense that you can't have a moving collector), but if you don't collect you can't get pointers inside a new object. Obviously imprecision is vastly preferable to instability. You can get around the imprecision by inserting zeroing ops at strategic places. Even if you omit this step the GC reliability is already much better than what we have now. > But if you have variable map with local liveness you > can as well add object/primitive distinction there and forget about > explicit separation in memory :) If you disambiguate local variables that can be used for both references and nonreferences your 'map' is reduced to a single bitmap per method, and the lookup function the GC uses can be correspondingly simple. If you also sort the locals the map reduces to a single index which is the boundary between the references and the nonreferences. I still think you need a full map for the JVM operand stack and/or registers. You can make them quite compact if you get clever about it. For example you can put a rudimentary disassembler in so the program can trace what's going on from the last 'safe point' to the current place. > AFAIK, hotspot stops thread, replaces closest safe points with some trap > and let thread run until it hit one. Then it restores original > instruction and voila. This sounds pretty ugly to me, since it involves lots of writing to the instruction stream with corresponding I-cache flushes etc. But it's doable and perhaps simpler than keeping stack maps around for all points. > Generally - it is hard. Not even stack maps and their representation, > but getting everything working with threads in efficient manner. Yes, I can see that. -- Erik Corry [EMAIL PROTECTED]
Re: Rewriting the GC
Erik wrote: > > The big problem with walking the stack isn't the Java stack as much as > > the native stack. You could walk the Java parts precisely, and the > > native bits conservatively, but I don't know what you'd win anything > > by doing this. > > OK, I'm not so familiar with the way Java interacts with > native code, but why do we need to walk the native bits at > all? Surely C code doesn't need GC? All the native methods in Kaffe, the threading system, the core class loading --- that's all written in C. That code uses the same stack as the Java code. That code uses Java object refereneces left and right, and stores them on the stack. I know the object allocation code in the GC itself relies on the GC scanning the stack to avoid collecting a brand new object (for whom the only reference is on the C stack). If you grep through the core of the VM, it invokes gc_malloc() a LOT. It definitely relies on the GC. Godmar and Tim cleaned things up a lot to avoid creating excessive walkable objects (e.g., many of the structures that hang off a class are explicitly allocated/deallocated) but there are still a significant number of GC objects that are created in C. > > As I understand GC trade-offs, the big win for precise GC is the > > ability to update pointers and thus implement a compacting collector. > > Is there something else you're hoping to get out of precise stack > > walking? > > Predictability and speed of GC. You're talking about bogus pointer references in a conservative scan being viewed as pointers, when in fact they're just integers that look like pointers? Most of the literature about that says the overhead is pretty small. I doubt you'd see any performance improvement (I guess things would get worse from having to manage stack maps and the like). As for predictability, I don't see that as a useful goal for Kaffe Remember, Kaffe already gets the benefits of precise GC for most objects. It is just thread stacks and objects for which it has no layout information or specific walk function that cause a conservative scan (and only for those objects). (I wonder what the other conservatively walked objects are, I think there are some still.) Implementating a compacting collector, OTOH, would be really cool. Kaffe could support generational collection (which is what all the "real" JVMs support AFAIK), and its support for multi-process VMs (the Flux work I do --- KaffeOS and JanosVM) would be much improved. That's just a significant amount of additional work, I believe. You could get an upperbound on the predictability by instrumenting the VM to count the number of references from a conservative scan are the only reference to an object. Many of those will be (I bet) legit references, but a precise stack walk cannot get rid of more than that... > > Another approach to consider is to implement GC-safe points (e.g., on > > method calls and backwards branches in Java code). Then you only have > > to track and update the stack maps at each safe point, > > There's a lot to be said for this, but since you can allocate > unlimited memory in an exception handler, every point that can > throw an exception has to be a safe point, which reduces the > appeal. Most call points and backwards branches would have to be gc-safe, anyway --- to avoid looong gaps without safe points --- so I don't think exceptions pose any significant problems. While you don't get major wins for the JIT'd code this way (though I think there are some nice ones) a system that supports safe points is (and I'm somewhat guessing here) much easier to write safe native code in --- you don't have to worry about your C code getting interrupted by the GC at arbitrary points, only at safe points you explicitly insert in your code. There are downsides, of course --- like if you forget to put a safe point in somewhere, the GC can be blocked for a long time. -Pat - - --- --- -- -- - - - Pat Tullmann www.tullmann.org "Forty-Two." -- Deep Thought
RE: JRE file layout for 1.0.7?
> Is anybody opposed to this? It is breaking with tradition > somewhat, and it's for the upcoming release, so I figured > it would be best to ask. It'll also impact the Debian and > RPM packages. > Go for it -- this will also allow side-by-side testing with other JRE implementations by resetting the JAVA_HOME variable when so desired. -Brent
Re: JRE file layout for 1.0.7?
Jim I'm all for it. That way, I can have Sun's JDK coresident with Kaffe. It may sound like anathema, but my bosses kinda prefer it that way ;-) Mark >From: "Jim Pick" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: <[EMAIL PROTECTED]> >Subject: JRE file layout for 1.0.7? >Date: Sat, 30 Mar 2002 09:14:28 -0800 > > >Hi, > >I want to minimize the number of changes for 1.0.7, in order to minimize >the >amount of surprises and I don't want to introduce new instabilities. > >But I would like to change the way the the files are installed when doing >"make install". Instead of installing it by default in /usr/local/bin, >/usr/local/lib, /usr/local/include, etc., I'd like to have the default >install put everything in /usr/local/kaffe, in a JRE-style layout. That >way, people could just set JAVA_HOME to point there, and use it instead of >a >regular JDK or JRE. Plus I've always disliked how the kaffe install places >those "java" and "javac" wrappers in /usr/local/bin. Also, I've been bit a >few times by kaffe versions I've been working on accidentally dynamically >loading the kaffe.org libs installed in /usr/local/lib instead of the libs >I >intended. > >Is anybody opposed to this? It is breaking with tradition somewhat, and >it's for the upcoming release, so I figured it would be best to ask. It'll >also impact the Debian and RPM packages. > >Cheers, > > - Jim > > > > _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
Re: Answer
On March 31, 2002 04:06 pm, Carlos Andres Cañaveral Usuga wrote: > I need work with jdbc for access to a database made on postgresql. It is > posible with kaffe and how? thanks This is possible. I got it working once on an HP425 workstation (how's that for a Kaffe port?) I can't remember what, if anything, special was required. Simply build the JDBC module for PostGresQL and go!
Re: Rewriting byte codes
Erik Corry wrote: > There's a lot to be said for this, but since you can allocate > unlimited memory in an exception handler, every point that can > throw an exception has to be a safe point [...] If exception is thrown, you don't care about registers (unless you write-cache locals in registers, but it will give problems even without precise gc), you don't care about stack. SO you only have to care about local var map, stack/register map is important only for safe points INSIDE exception handler. Local var map can be optimized, as it is common for a lot of places in code (so for method you would just create few maps with ranges of addresses for which they are valid). I'm afraid that you will not be able to avoid making stack maps and using safe points. You need to know about registers - I don't think that splitting register into reference and non-reference is reasonable on i86. You also need to mark which local variables are live and which are dead - because if you will use dead object pointers as live, you are non-precise and possibly unstable (as it can point inside some newly allocated object). But if you have variable map with local liveness you can as well add object/primitive distinction there and forget about explicit separation in memory :) Safe points should be made on new/newarray/multinewarray monitorenter/monitorexit method call backward branch First three are obvious, backward branch is for tight loops which got preempted and are possibly endless, but gc needs to run (you cannot create endless loop with forward branches, so it is not a problem). AFAIK, hotspot stops thread, replaces closest safe points with some trap and let thread run until it hit one. Then it restores original instruction and voila. Generally - it is hard. Not even stack maps and their representation, but getting everything working with threads in efficient manner. Artur
Answer
I need work with jdbc for access to a database made on postgresql. It is posible with kaffe and how? thanks -- Get your free email from www.linuxmail.org Powered by Outblaze
Re: Rewriting byte codes
On Sun, Mar 31, 2002 at 08:41:34PM -0700, Patrick Tullmann wrote: > Erik wrote: > > I'd like to make some changes to Kaffe to make it simpler to do more > > precise GC. > > Just for reference, so everyone's on the same page, Kaffe already does > precise walking of Java objects (see gcFuncs.c:walkObject()). It does > not precisely walk stacks. I believe it walks many native objects > (like jthreads, etc) conservatively. > > The big problem with walking the stack isn't the Java stack as much as > the native stack. You could walk the Java parts precisely, and the > native bits conservatively, but I don't know what you'd win anything > by doing this. OK, I'm not so familiar with the way Java interacts with native code, but why do we need to walk the native bits at all? Surely C code doesn't need GC? > As I understand GC trade-offs, the big win for precise GC is the > ability to update pointers and thus implement a compacting collector. > Is there something else you're hoping to get out of precise stack > walking? Predictability and speed of GC. > Another approach to consider is to implement GC-safe points (e.g., on > method calls and backwards branches in Java code). Then you only have > to track and update the stack maps at each safe point, There's a lot to be said for this, but since you can allocate unlimited memory in an exception handler, every point that can throw an exception has to be a safe point, which reduces the appeal. -- Erik Corry [EMAIL PROTECTED] Citér kun det nødvendige. Slet denne signature. Svar under det citerede.
