Re: Bytecode & analyse
Thierry Rochelet wrote: Philippe Laporte wrote: > > Thierry Rochelet wrote: >Hallo, > je ne suis pas certain du sens de votre question. Vous > suggerez d'utiliser ces outils pour parser le bytecode? > > Regards, > Non, pas du tout. Un collegue m'a mis en tete l'idee qu'utiliser flex/bison pour faire un analyseur de bytecodes est la plus performante. N'etant pas certain (apres avoir teste) du bien fonde de cette affirmation, je demande juste l'avis des pros. Voila,mais, je ne suggere en aucun cas l'utilisation de ces outils ! Merci Thierry > -- > Philippe Laporte Tel: (415) 243-4055 ext 1011 > Transvirtual Technologies, Inc., Fax: (415) 243-4056 > San Francisco, CA, USA. Email: [EMAIL PROTECTED] > > ca serait beaucoup moins performant Etes vous etudiant? A plus tard -- Philippe Laporte Tel: (415) 243-4055 ext 1011 Transvirtual Technologies, Inc., Fax: (415) 243-4056 San Francisco, CA, USA. Email: [EMAIL PROTECTED]
Re: Bytecode & analyse
Thierry Rochelet wrote: Hi, I have a few question about bytecode analyse and the Kaffe development. What about using tools such as Flex/Bison ? Why don't you choose that way ? Thanks. Thierry Hallo, je ne suis pas certain du sens de votre question. Vous suggerez d'utiliser ces outils pour parser le bytecode? Regards, -- Philippe Laporte Tel: (415) 243-4055 ext 1011 Transvirtual Technologies, Inc., Fax: (415) 243-4056 San Francisco, CA, USA. Email: [EMAIL PROTECTED]
Re: I don't want to receive some MAILS anymore
Julien Grépillat wrote: I don't want to receive some MAILS anymore je crois plutot que vous ne voulez pas recevoir ALL or ANY mails -- Philippe Laporte Tel: (510) 527-4025 ext 14 Transvirtual Technologies, Inc., Fax: (510) 559-3287 San Francisco, CA, USA. Email: [EMAIL PROTECTED]
Re: kaffe native interface
Hi, the second explanation is the right one You can find plenty of documentation on the JNI at http://www.transvirtual.com/~peter/native/ Regards, -- Philippe Laporte Tel: (510) 527-4025 ext 14 Transvirtual Technologies, Inc., Fax: (510) 559-3287 Berkeley, CA, USA.Email: [EMAIL PROTECTED] Nic Ferrier wrote: > Kaffe uses 2 different native interfaces... "native" seems to be kaffe > specific but also the standard jni. > > Is there a design reason for this? Is native more efficient? > > Or is it simply that jni was firmed up long after most of kaffe was > written and "native" is the historic native interface for Kaffe? > > Nic Ferrier
Re: Kaffe memory minimum
Hi, If you are enthusiastic about having Kaffe run on embedded systems, you might liketo take a look at the pocketlinux project, which uses Kaffe. Regards, -- Philippe Laporte Tel: (510) 527-4025 ext 14 Transvirtual Technologies, Inc., Fax: (510) 559-3287 Berkeley, CA, USA. Email: [EMAIL PROTECTED] Javier Garcia wrote: Hi everybody. I'm still trying to install Kaffe in an embedded system, with a lot of limitations of memory. The goal is to have it using a total amount of dynamic memory (included all the stacks and the binaries) of around 5Mb. I have downloaded the last version, and I have installed it with the next line to configure: >>configure --enable-dependency-tracking --with-engine=intrp --disable-debug --disable-xprofiling --disable-xdebugging --disable-feedback --without-profiling --without-suncompat --without-x --without-stats And I got a size of the binaries of 2.444 Mb. But the 'big' problem is the heap (because I think the other two stacks (Java and native) are quite small). When I try to execute some test programs with a maximum heap size of 5 Mb (minimum heap size 5Mb also) I get a 'Out of memory' error, so I haven't even tried to use a smaller heap. Anybody knows if it's possible to have everything running with 5 Mb (binaries and stacks). And if it's possible, how to do it? Thanks for all in advance. Javi. P.D. I have seen somewhere an option for configure: --with-optimize-memory. I haven't tried it, I'll do and I'll tell you. ___ Do You Yahoo!? Envía mensajes instantáneos y recibe alertas de correo con Yahoo! Messenger - http://messenger.yahoo.es
Re: Running VM State - Modification, Complexity, Cleanliness
Hi, you can find a pretty good description of Sun's VM implementation in the following book. Sun is "very proud" and so will discuss/disclose almost anything. http://java.sun.com/docs/books/performance/ Kaffe is not very much documented. You can find some description of some of its parts at http://www.CS.McGill.CA/~laporte/kaffereport/report.html Regards, -- Philippe Laporte Tel: (510) 527-4025 ext 14 Transvirtual Technologies, Inc., Fax: (510) 559-3287 Berkeley, CA, USA. Email: [EMAIL PROTECTED] Nathan Meyers wrote: On Mon, Feb 12, 2001 at 07:08:24AM -0800, Steve Sansha wrote: > Also: Does the Virtual Machine allow self-modifying > code? I'm sure it's possible for the bytecode to > create a new byte[] and use custom-built classloader > to actually load it, but is their an easier > alternative? > (I'm guessing it's not, since it's a type-safe > language) You may find a broken VM implementation that lets you do such a thing, but Java's pretty strict about access to memory. Writing into space occupied by loaded bytecodes isn't in spec. And, with the possibility that the code has been JITted, changing bytecodes on the fly would be very bad news. Custom classloaders are easy to write - there really is no "easier alternative". Loading your own manufactured bytecodes requires an almost trivial subclass of ClassLoader. > Also: I'm sending this to Kaffe because it seems to be > the best-documented, best-spirited VM... But just so I > > know, are their any documents (except the in-source > code documentation) for Sun's reference > implementation? I've looked around and can't find > any. Sun publishes detailed specs about the language, the JVM, the classfile format, and such. As for details on JVM implementation - I doubt it. And that's a moving target anyway. Nathan > > (Thanks * 1,000,000) -Steve > > > __ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail - only $35 > a year! http://personal.mail.yahoo.com/
Re: Kaffe JIT: what does it do? really no porting doc?
Hi, I think the following is a decent beginning explanation of the Kaffe JIT: http://www.CS.McGill.CA/~laporte/kaffereport/report.html Tell me what you think, -- Philippe Laporte Tel: (510) 527-4025 ext 14 Transvirtual Technologies, Inc., Fax: (510) 559-3287 Berkeley, CA, USA.Email: [EMAIL PROTECTED] On Tuesday 16 January 2001 09:06, Aaron Van Couwenberghe wrote: > On Tue, Dec 26, 2000 at 12:36:03PM +0100, Renaud Marlet wrote: > > Hi, > > > > Looking at the Kaffe web site and at the source code, I have not been > > able to clearly understand what the Kaffe JIT was doing. > > - does it do anything more than removing the interpretation loop > > and the operand stack? > > - how is register allocation performed? (I have not seen a separate > > phase but rather what looks like an "on-the-fly" allocation.) > > - what are differences between JIT and JIT3 (besides that it runs > > faster)? > > > > The web site says "Porting Kaffe's JIT compiler is a much more > > complex undertaking. It requires you to define the instruction > > set and register architecture of a given platform. See config/*/jit* > > for examples. We would welcome documentation here." Is it really > > the case that there currently is no documentation to guide porting? > > > > Thanks, > > > > Renaud Marlet > > -- > > http://www.trusted-logic.fr -- Tel +33 1 30 97 25 08 (Fax 25 19) > > http://www.irisa.fr/compose/marlet > > Not quite. I asked a similar question some time ago on this list, and there > is a document floating around the web that gives at least a bit of detail. > The title has something to do with springboards But the document went > over one architecture piece by piece.
Re: Ahead Of Time compilation with Kaffe
please await Tim's comment on this matter On Tuesday 19 December 2000 17:56, Marcus Smith wrote: > On Tue, 19 Dec 2000 18:34:20 Philippe Laporte wrote: > > On Tuesday 19 December 2000 17:14, Marcus Smith wrote: > > > On Tue, 19 Dec 2000 15:15:26 Philippe Laporte wrote: > > > > If you mean simply to compile the classes before running them, this > > > > is > > > > > > done > > > > with gcj in the pocketlinux version > > > > > > > > Regards, > > > > -- > > > > Philippe Laporte Tel: (510) 527-4025 ext 14 > > > > Transvirtual Technologies, Inc., Fax: (510) 559-3287 > > > > Berkeley, CA, USA.Email: > > > > [EMAIL PROTECTED] > > > > > >On Tuesday 19 December 2000 13:40, Marcus Smith wrote: > > > > > Hi, > > > > > > > > > > Has anyone looked at "Ahead Of Time" compilation with Kaffe? > > > > > > > > > > Marcus Smith > > > > > > Does this create native code at compile time? > > > > > > Marcus > > > > yes > > > > -- > > Philippe Laporte Tel: (510) 527-4025 ext 14 > > Transvirtual Technologies, Inc., Fax: (510) 559-3287 > > Berkeley, CA, USA.Email: [EMAIL PROTECTED] > > I read in the Kaffe 1.0.6 gcj FAQ that this "feature" has been turned off > since gcc 2.96 broke it (somehow). > Are you saying that transvirtual has fixed this and it exists in the > transvirtual cvs repository? > > Marcus -- Philippe Laporte Tel: (510) 527-4025 ext 14 Transvirtual Technologies, Inc., Fax: (510) 559-3287 Berkeley, CA, USA.Email: [EMAIL PROTECTED]
Re: Ahead Of Time compilation with Kaffe
On Tuesday 19 December 2000 17:14, Marcus Smith wrote: > On Tue, 19 Dec 2000 15:15:26 Philippe Laporte wrote: > > If you mean simply to compile the classes before running them, this is > > done > > with gcj in the pocketlinux version > > > > Regards, > > -- > > Philippe Laporte Tel: (510) 527-4025 ext 14 > > Transvirtual Technologies, Inc., Fax: (510) 559-3287 > > Berkeley, CA, USA.Email: [EMAIL PROTECTED] > > > >On Tuesday 19 December 2000 13:40, Marcus Smith wrote: > > > Hi, > > > > > > Has anyone looked at "Ahead Of Time" compilation with Kaffe? > > > > > > Marcus Smith > > Does this create native code at compile time? > > Marcus yes -- Philippe Laporte Tel: (510) 527-4025 ext 14 Transvirtual Technologies, Inc., Fax: (510) 559-3287 Berkeley, CA, USA.Email: [EMAIL PROTECTED]
Re: Ahead Of Time compilation with Kaffe
I'll let Tim answer that one when he comes back from all over the place -:) Regards, -- Philippe Laporte Tel: (510) 527-4025 ext 14 Transvirtual Technologies, Inc., Fax: (510) 559-3287 Berkeley, CA, USA.Email: [EMAIL PROTECTED] On Tuesday 19 December 2000 15:11, Patrick Tullmann wrote: > Philippe Laporte wrote: > > If you mean simply to compile the classes before running them, this > > is done with gcj in the pocketlinux version > > Whoa! Really? I know `vanilla' Kaffe has some rudimentary support > for GCJ; is that what the pocketlinux version uses? Has it been > improved from what is in Kaffe? > > Are there any plans to merge the stock Kaffe tree and the pocketlinux > Kaffe tree? Or are you guys forking your own open source project?? > > -Pat > > - - --- --- -- -- - - - > Pat Tullmann [EMAIL PROTECTED] > A closed mouth gathers no foot.
Re: Ahead Of Time compilation with Kaffe
If you mean simply to compile the classes before running them, this is done with gcj in the pocketlinux version Regards, -- Philippe Laporte Tel: (510) 527-4025 ext 14 Transvirtual Technologies, Inc., Fax: (510) 559-3287 Berkeley, CA, USA.Email: [EMAIL PROTECTED] On Tuesday 19 December 2000 13:40, Marcus Smith wrote: > Hi, > > Has anyone looked at "Ahead Of Time" compilation with Kaffe? > > Marcus Smith
Re: Re[2]: slowLockMutex / putHeavyLock
A little bit unrelated, but you may put
else if ((val - (uintp)where) > (STACKREDZONE / 2) )
to optimize hopefully a bit
Regards,
--
Philippe Laporte
Optimization Engineer Tel: (510) 527-4025 ext 14
Transvirtual Technologies, Inc., Fax: (510) 559-3287
Berkeley, CA, USA.Email: [EMAIL PROTECTED]
On Thursday 30 November 2000 17:54, Godmar Back wrote:
> > /*
> > * Lock a mutex - try to do this quickly but if we failed because
> > * we can't determine if this is a multiple entry lock or we've got
> > * contention then fall back on a slow lock.
> > */
> > void
> > _lockMutex(iLock** lkp, void* where)
> > {
> > uintp val;
> >
> > val = (uintp)*lkp;
> >
> > if (val == 0) {
> > if (!COMPARE_AND_EXCHANGE(lkp, 0, (iLock*)where)) {
> > slowLockMutex(lkp, where);
> > }
> > }
> > else if (val - (uintp)where > 1024) {
> > /* XXX count this in the stats area */
> > slowLockMutex(lkp, where);
> > }
> > }
> >
> > as you see - lkp is not protected at all.
> > If val != 0, this doesn't mean that in next
> > statement it's != 0, i.e. in this time another
> > thread may execute some code to change lkp.
>
> If *lkp becomes null, that means some other thread
> unlocked the mutex since - we can still safely call slowLockMutex.
> (Worst thing that happens will be that we'll put a heavy lock in
> place where we don't need one - a small optimization in slowLockMutex
> avoids that ...)
>
> The only situation in which we rely on the value read from *lkp is when
> it's != 0 && *lkp - where <= 1024. However, in this situation
> we're holding the lock already so no other thread can write *lkp.
> This is a recursive enter.
>
> There are two undocumented assumptions here: namely that
> LOCK_INPROGRESS - where > 1024, because *lkp can be LOCK_INPROGRESS,
> and that the stack grows down. This is all perfectly 64bit safe and
> architecture-independent.
>
> > Actually, all code related to lkp must be under
> > jthread_spinon/jthread_spinoff protection, right?
>
> I don't believe so.
> That would defeat the whole purpose of fast synchronization.
>
> The COMPARE_AND_EXCHANGE must be atomic, and not the bogus
> one in locks.c (do what Pat suggested.)
>
> - Godmar
Re: Add javax.* packages
Hi, well it is not real real-time -:), but rather, the threads are scheduled within the real-time scheduling class of Linux, which is soft realtime. I don't know when it will be merged in with the OpenVM version, although this has been announced, so it should be in the near future. In the mean-time I can send anyone the few files needed for soft real-time on linux. I do not have performance benchmarks yet, but I did get a significant improvemnt on a single benchmark I use which I find to strain the mem alloc, gc and string manipulation apsects of java performance. Our ultimate goat at TVT is to have pocketlinux run under pthreads real-time. Regards, -- Philippe Laporte Optimization Engineer Tel: (510) 527-4025 ext 14 Transvirtual Technologies, Inc., Fax: (510) 559-3287 Berkeley, CA, USA. Email: [EMAIL PROTECTED] Erik Hu wrote: Hi Philippe Based on RTSJ (www.rtj.org) proposal, I have recently modified Kaffe for real-time applications. The previous implementation has created a javax.realtime package and modified the Kaffe VM for real-time purpose (jthread) under Linux. The modification of Kaffe VM includes the priority inheritance protocol, management of RealtimeThread and PeriodicThread, and other modifications. In fact, the previous version was missing the memory modifications and some other classes of the RTSJ specification. I also simplified the creation of javax.realtime package into Klasses.jar (Klasses.jar = java.lang.* + javax.realtime.*). Now, Cris is going to complete some lacking parts of my previous implementation and separate the javax.realtime package from Klasses.jar. Could you please tell us your current achievement of pthreads porting for Real-time applications ? When will the ptherad real-time of Kaffe be merged into traditional Open Kaffe VM ? Regards,Erik - Original Message - From:Philippe Laporte To: [EMAIL PROTECTED] Sent: Monday, November 20, 2000 4:39 PM Subject: Re: Add javax.* packages Hi, I am very interested in this project. Can you share what modifications you made, and what are your goals? I have recently done the pthreads soft real-time port of Kaffe under linux. Thank you, -- Philippe Laporte Optimization Engineer Tel: (510) 527-4025 ext 14 Transvirtual Technologies, Inc., Fax: (510) 559-3287 Berkeley, CA, USA. Email: [EMAIL PROTECTED]
Re: Add javax.* packages
Hi, I am very interested in this project. Can you share what modifications you made, and what are your goals? I have recently done the pthreads soft real-time port of Kaffe under linux. Thank you, -- Philippe Laporte Optimization Engineer Tel: (510) 527-4025 ext 14 Transvirtual Technologies, Inc., Fax: (510) 559-3287 Berkeley, CA, USA. Email: [EMAIL PROTECTED] C Pedley wrote: Surely the Makefile.in files are automatically generated from the Makefile.am files and do not require modification. I forgot to mention the first time that I have also updated the configure.in file. I am sure I wish to do this as I'm implementing the javax.realtime package on top of a modified kaffe. On Thu, 16 Nov 2000, Nic Ferrier wrote: > > >>> C Pedley <[EMAIL PROTECTED]> 16-Nov-00 11:57:15 AM >>> > > >My approach so far has been: I have a new package I wish > >to create, say called javax.new So I created a new folder > >in the libraries/extensions folder, and then copied the > >directory structure and makefile.am format from the servlet > >package that is located here (obviously changing "servlet" > >to "new" wherever this is appropriate). However, when > >attempting to use these makefiles an error is thrown as > >it doesn't know how to build the new.jar archive. Any > >ideas? > > You have to alter the Makefile.in and run automake if you want to > change the distrib. > > But are you sure you want to do that? > > > Nic >
Re: incremental gc
Sorry, yet, the two versions will be merged soon enough Regards Godmar Back wrote: > > > > Concurrent incremental gc is in development and should be integrated > > in the near future. In kaffe 1.0.6, it is mem2. > > > > mem2 is only in Transvirtual's still private tree. It's not part > of the public tree, and neither is it part of 1.0.6. > > - Godmar
Re: incremental gc
Hi, Concurrent incremental gc is in development and should be integrated in the near future. In kaffe 1.0.6, it is mem2. -- Philippe Laporte Optimization Engineer Tel: (510) 527-4025 ext 14 Transvirtual Technologies, Inc., Fax: (510) 559-3287 Berkeley, CA, USA. Email: [EMAIL PROTECTED] Fang Wei Jian wrote: Until now, there is no incremental gc implementation in kaffe. Incremental gc is of necessity to provide a non-disruptive java program execution, especially when working in a real-time or interactive environment. Is there any plan to implement incremental gc in kaffe? fwj
