Thread: RE: [Sablevm-user] hello
Brought to you by:
egagnon
Menu
▾
▴
sablevm-user
|
From: Alan L. <al...@in...> - 2004-04-18 18:33:16
|
Etienne, would you have any hard numbers for a 'reasonable' system? We are looking for an embeddable JVM ourselves. Kaffe requires a heap = size of > 1 meg just to do a 'hello world'. How would Sable compare = against that? (Better I hope!).=20 Do you happen to know if anyone has tried to 'cldc-ise' Sable and what = kind of footprint that might result in ?? Performance-wise do you have a feel for how Sable might compare against = the threaded-int version of Kaffe (which I guess just about sets our = minimum acceptable level of performance) ? Thanks Alan -----Original Message----- From: sab...@li... = [mailto:sab...@li...] On Behalf Of Etienne = Gagnon Sent: Sunday, April 18, 2004 10:10 AM To: Vladimir Levin Cc: sab...@li... Subject: Re: [Sablevm-user] hello Vladimir Levin wrote: > I am looking at using Java for embedded development. I am wondering if > SableVM is suitable for embedded development? How does it compare to = GCJ? SableVM's runtime memory footprint can be pretty low, I guess. You can = setup the initial heap size to 0 byte, and the increment to 1 byte, so = that SableVM will tend to have as small a heap as possible (somewhat). Also, you can compile it with -Os, to optimize size. [Many of the m4 = macros in place to add robustness can be easily modified to expand to = even smaller code.] At runtime, the bytecode gets very little expansion (for preparation), = compared to compiled code (gross figure; some times it's the other way = around for specific bytecode sequences). SableVM is a "traditional" kind of JVM; it does no ahead of time = compiling, not runtime compilation. It can result in smaller code. = But, it will not compete in speed with highly optimized code, or = adaptive optimization systems such as JikesRVM. Etienne --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of = GenToo technologies. Learn everything from fundamentals to system = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck _______________________________________________ Sablevm-user mailing list Sab...@li... https://lists.sourceforge.net/lists/listinfo/sablevm-user --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004 =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004 =20 |
|
From: Alan L. <al...@in...> - 2004-04-18 20:07:38
|
Etienne, I'd be more than happy to do that, but if you had some basic ideas as = to size it would be really useful in helping me decide whether it is = worth it or not (sorry to sound lazy but I have a full plate here). Kaffe (or rather Kangaroo - a CLDC'ised version) seems to need at = footprint of 2 megs to get anything done. Do you think Sable could come = in under that ?? Tnx Alan -----Original Message----- From: Etienne Gagnon [mailto:gag...@uq...]=20 Sent: Sunday, April 18, 2004 12:23 PM To: Alan Littleford Cc: sab...@li... Subject: Re: [Sablevm-user] hello Hi Alan, You could grab SableVM's source code and do test it for yourself and = hopefully report back the results here. You can set SableVM's memory consupmtion properties using: sablevm.heap.size.min sablevm.heap.size.max // 0 means no max. sablevm.heap.size.increment = // 0 means fixed-size heap e.g. $ sablevm --property=3Dsablevm.heap.size.min=3D1024 = --property=3Dsablevm.heap.size.increment=3D1024 ... This would start with a 1K heap and increase it by 1K increments, when = needed. You can also customize other memory consuption things like stack = size/growth, and class-loading related memory. All these properties are = defined in src/libsablevm/vm_args.m4.c = http://devel.sablevm.org/svn/repository/sablevm/branches/staging/src/libs= ablevm/vm_args.m4.c Looking forward to see your results! Etienne Alan Littleford wrote: > Etienne, >=20 > would you have any hard numbers for a 'reasonable' system? >=20 > We are looking for an embeddable JVM ourselves. Kaffe requires a heap=20 > size of > 1 meg just to do a 'hello world'. How would Sable compare = against that? (Better I hope!). >=20 > Do you happen to know if anyone has tried to 'cldc-ise' Sable and what = > kind of footprint that might result in ?? >=20 > Performance-wise do you have a feel for how Sable might compare=20 > against the threaded-int version of Kaffe (which I guess just about=20 > sets our minimum acceptable level of performance) ? >=20 > Thanks >=20 > Alan >=20 >=20 >=20 >=20 > -----Original Message----- > From: sab...@li...=20 > [mailto:sab...@li...] On Behalf Of Etienne = Gagnon > Sent: Sunday, April 18, 2004 10:10 AM > To: Vladimir Levin > Cc: sab...@li... > Subject: Re: [Sablevm-user] hello >=20 >=20 > Vladimir Levin wrote: >=20 >>I am looking at using Java for embedded development. I am wondering if = >>SableVM is suitable for embedded development? How does it compare to=20 >>GCJ? >=20 >=20 > SableVM's runtime memory footprint can be pretty low, I guess. You=20 > can setup the initial heap size to 0 byte, and the increment to 1=20 > byte, so that SableVM will tend to have as small a heap as possible=20 > (somewhat). >=20 > Also, you can compile it with -Os, to optimize size. [Many of the m4=20 > macros in place to add robustness can be easily modified to expand to=20 > even smaller code.] >=20 > At runtime, the bytecode gets very little expansion (for preparation), = > compared to compiled code (gross figure; some times it's the other way = > around for specific bytecode sequences). >=20 > SableVM is a "traditional" kind of JVM; it does no ahead of time=20 > compiling, not runtime compilation. It can result in smaller code. =20 > But, it will not compete in speed with highly optimized code, or=20 > adaptive optimization systems such as JikesRVM. >=20 > Etienne >=20 --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004 =20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.659 / Virus Database: 423 - Release Date: 4/15/2004 =20 |
|
From: Etienne G. <gag...@uq...> - 2004-04-18 22:01:17
|
There's a pre-compiled Debian package. Running it as: $ sablevm --property=sablevm.heap.size.min=1024 --property=sablevm.heap.size.increment=1024 --property=sablevm.classloader.heap.size.min=1024 --property=sablevm.classloader.heap.size.increment=1024 --property=sablevm.stack.size.min=1024 --property=sablevm.stack.size.increment=1024 -Y HelloWorld then ^z (quickly!!!) to send to sleep then ps to retrieve process id then cat /proc/16729/status gives: State: T (stopped) Tgid: 16729 Pid: 16729 PPid: 16711 TracerPid: 0 Uid: 1000 1000 1000 1000 <egagnon> Gid: 1000 1000 1000 1000 <egagnon> FDSize: 256 <egagnon> Groups: 1000 6 24 25 29 40 44 60 100 101 1002 1011 1016 1019 1021 <egagnon> VmSize: 3836 kB <egagnon> VmLck: 0 kB <egagnon> VmRSS: 2100 kB <egagnon> VmData: 1600 kB <egagnon> VmStk: 20 kB <egagnon> VmExe: 12 kB <egagnon> VmLib: 2120 kB <egagnon> SigPnd: 0000000000000000 <egagnon> SigBlk: 0000000080000000 <egagnon> SigIgn: 0000000000000000 <egagnon> SigCgt: 0000000380000684 <egagnon> CapInh: 0000000000000000 <egagnon> CapPrm: 0000000000000000 <egagnon> CapEff: 0000000000000000 So, it uses 1.6M of non-shared memory. Now, this is a stock -O2 compiled sablevm, with an inlined interpreter engine (the biggest one in size). So, you might want to further investigate. :-) Etienne. Alan Littleford wrote: > Etienne, > > I'd be more than happy to do that, but if you had some basic ideas as to size it would be really useful in helping me decide whether it is worth it or not (sorry to sound lazy but I have a full plate here). > > Kaffe (or rather Kangaroo - a CLDC'ised version) seems to need at footprint of 2 megs to get anything done. Do you think Sable could come in under that ?? > > Tnx > Alan > > > -----Original Message----- > From: Etienne Gagnon [mailto:gag...@uq...] > Sent: Sunday, April 18, 2004 12:23 PM > To: Alan Littleford > Cc: sab...@li... > Subject: Re: [Sablevm-user] hello > > > Hi Alan, > > You could grab SableVM's source code and do test it for yourself and hopefully report back the results here. > > You can set SableVM's memory consupmtion properties using: > > sablevm.heap.size.min > sablevm.heap.size.max // 0 means no max. sablevm.heap.size.increment // 0 means fixed-size heap > > e.g. > > $ sablevm --property=sablevm.heap.size.min=1024 --property=sablevm.heap.size.increment=1024 ... > > This would start with a 1K heap and increase it by 1K increments, when needed. > > You can also customize other memory consuption things like stack size/growth, and class-loading related memory. All these properties are defined in src/libsablevm/vm_args.m4.c http://devel.sablevm.org/svn/repository/sablevm/branches/staging/src/libsablevm/vm_args.m4.c > > Looking forward to see your results! > > Etienne > > Alan Littleford wrote: > >>Etienne, >> >> would you have any hard numbers for a 'reasonable' system? >> >>We are looking for an embeddable JVM ourselves. Kaffe requires a heap >>size of > 1 meg just to do a 'hello world'. How would Sable compare against that? (Better I hope!). >> >>Do you happen to know if anyone has tried to 'cldc-ise' Sable and what >>kind of footprint that might result in ?? >> >>Performance-wise do you have a feel for how Sable might compare >>against the threaded-int version of Kaffe (which I guess just about >>sets our minimum acceptable level of performance) ? >> >>Thanks >> >>Alan >> >> >> >> >>-----Original Message----- >>From: sab...@li... >>[mailto:sab...@li...] On Behalf Of Etienne Gagnon >>Sent: Sunday, April 18, 2004 10:10 AM >>To: Vladimir Levin >>Cc: sab...@li... >>Subject: Re: [Sablevm-user] hello >> >> >>Vladimir Levin wrote: >> >> >>>I am looking at using Java for embedded development. I am wondering if >>>SableVM is suitable for embedded development? How does it compare to >>>GCJ? >> >> >>SableVM's runtime memory footprint can be pretty low, I guess. You >>can setup the initial heap size to 0 byte, and the increment to 1 >>byte, so that SableVM will tend to have as small a heap as possible >>(somewhat). >> >>Also, you can compile it with -Os, to optimize size. [Many of the m4 >>macros in place to add robustness can be easily modified to expand to >>even smaller code.] >> >>At runtime, the bytecode gets very little expansion (for preparation), >>compared to compiled code (gross figure; some times it's the other way >>around for specific bytecode sequences). >> >>SableVM is a "traditional" kind of JVM; it does no ahead of time >>compiling, not runtime compilation. It can result in smaller code. >>But, it will not compete in speed with highly optimized code, or >>adaptive optimization systems such as JikesRVM. >> >>Etienne >> > > > -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Etienne G. <gag...@uq...> - 2004-04-18 19:42:08
|
Hi Alan, You could grab SableVM's source code and do test it for yourself and hopefully report back the results here. You can set SableVM's memory consupmtion properties using: sablevm.heap.size.min sablevm.heap.size.max // 0 means no max. sablevm.heap.size.increment // 0 means fixed-size heap e.g. $ sablevm --property=sablevm.heap.size.min=1024 --property=sablevm.heap.size.increment=1024 ... This would start with a 1K heap and increase it by 1K increments, when needed. You can also customize other memory consuption things like stack size/growth, and class-loading related memory. All these properties are defined in src/libsablevm/vm_args.m4.c http://devel.sablevm.org/svn/repository/sablevm/branches/staging/src/libsablevm/vm_args.m4.c Looking forward to see your results! Etienne Alan Littleford wrote: > Etienne, > > would you have any hard numbers for a 'reasonable' system? > > We are looking for an embeddable JVM ourselves. Kaffe requires a heap size of > 1 meg just to do a 'hello world'. How would Sable compare against that? (Better I hope!). > > Do you happen to know if anyone has tried to 'cldc-ise' Sable and what kind of footprint that might result in ?? > > Performance-wise do you have a feel for how Sable might compare against the threaded-int version of Kaffe (which I guess just about sets our minimum acceptable level of performance) ? > > Thanks > > Alan > > > > > -----Original Message----- > From: sab...@li... [mailto:sab...@li...] On Behalf Of Etienne Gagnon > Sent: Sunday, April 18, 2004 10:10 AM > To: Vladimir Levin > Cc: sab...@li... > Subject: Re: [Sablevm-user] hello > > > Vladimir Levin wrote: > >>I am looking at using Java for embedded development. I am wondering if >>SableVM is suitable for embedded development? How does it compare to GCJ? > > > SableVM's runtime memory footprint can be pretty low, I guess. You can setup the initial heap size to 0 byte, and the increment to 1 byte, so that SableVM will tend to have as small a heap as possible (somewhat). > > Also, you can compile it with -Os, to optimize size. [Many of the m4 macros in place to add robustness can be easily modified to expand to even smaller code.] > > At runtime, the bytecode gets very little expansion (for preparation), compared to compiled code (gross figure; some times it's the other way around for specific bytecode sequences). > > SableVM is a "traditional" kind of JVM; it does no ahead of time compiling, not runtime compilation. It can result in smaller code. But, it will not compete in speed with highly optimized code, or adaptive optimization systems such as JikesRVM. > > Etienne > -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Grzegorz B. P. <ga...@de...> - 2004-04-19 04:52:11
|
On (18/04/04 11:33), Alan Littleford wrote: > Performance-wise do you have a feel for how Sable might compare against > the threaded-int version of Kaffe (which I guess just about sets our > minimum acceptable level of performance) ? It will surely be much faster. On the 118th page of http://www.sable.mcgill.ca/publications/thesis/phd-gagnon/sable-thesis-2002-phd-gagnon.pdf you'll find results for a number of benchmarks and applications. They show, that that Kaffe's interpreter is 3.5 to 7 times slower than SableVM. At the same time SableVM's performance was very near Sun's JDK interpteter, which (as informed sources say) is partially written in assembly (SableVM is pure C). In comparision with JITs SableVM's interpreter achieved ex. from 0.17 to 0.88 performance of JikesRVM (for biger, real-life applications like Soot and SableCC SableVM achieved 0.88 and 0.75 performance of JikesRVM!). We all know that there are lies, big lies and benchmarks, but this should give you some picture of what to expect. HTH Grzegorz B. Prokopski PS: All these results were for "inlined" engine, which is the fastest one. On embedded systems, with RAM memory constraints, you might want to use "direct" instead, so the performance can be slightly degraded. See page 40 of the above PDF for details. -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM |
|
From: Grzegorz B. P. <ga...@de...> - 2004-04-20 04:41:56
|
On (18/04/04 23:10), Grzegorz B. Prokopski wrote: > In comparision with JITs SableVM's interpreter achieved ex. from 0.17 to > 0.88 performance of JikesRVM (for biger, real-life applications like Soot > and SableCC SableVM achieved 0.88 and 0.75 performance of JikesRVM!). I've unconsciously overlooked an important thing: this was comparison with JikesRVM *baseline* compiler, not the optimizing one! :) Sorry for confusion. But still, this is comparison betwen an interpreter and a JIT! (though a simple one) GBP -- Grzegorz B. Prokopski <ga...@de...> Debian GNU/Linux http://www.debian.org SableVM - LGPLed JVM http://www.sablevm.org Why SableVM ?!? http://devel.sablevm.org/wiki/WhySableVM |
|
From: Dalibor T. <ro...@ka...> - 2004-04-19 08:31:10
|
Grzegorz B. Prokopski <gadek <at> debian.org> writes: > They show, that that Kaffe's interpreter is 3.5 to 7 times slower than > SableVM. At the same time SableVM's performance was very near Sun's JDK > interpteter, which (as informed sources say) is partially written in > assembly (SableVM is pure C). That's the 'normal', naive intepreter in kaffe, as far as I can tell from the paper. There is a threaded-interpreter patch for kaffe here: http://www.complang.tuwien.ac.at/java/kaffe-threaded/ but it hasn't been merged in into the kaffe sources yet, and the internal APIs have changed since the version the patch is against, so it probably won't apply cleanly. Jim Huang is looking into merging it in into kaffe's CVS, but it's not there yet. The web site mentions an up to 3 fold increase in performance over the naive interpreter using a possibly patent encumbered technique. I've got no idea whether the mentioned patent really holds water or not, I assume Etienne might know more about it. In any case, since Etienne's benchmarks show up to 7 times better results for SableVM's interpreter, chances are that even with the threaded interpreter patch SableVM's implementation would outperform Kaffe's interpreter. cheers, dalibor topic |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X