|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
IDE是好。java中的IDE更是百花齐放,你用jbuilder能说jbuilder赶不上vs吗?用eclipse,netbeans也很舒服啊。我就不明白“稍微差一些”那一些是从哪里差来的。JavaVMl展
JimHuang<jimchyun@ccns.ncku.edu.tw>
<jserv@kaffe.org>
略檎砉P者JavaVM作的心得,cT位分享,在本文後半部W㈧度舾
OpenSourceJavaVM0傅奶接,P者自己是KaffeVM[1]_l者,很但愿本文
能促挠兴助,更等候您的硇胖附蹋逵杉夹g交换,KaffeVM有更好的l
展。
[1]http://www.kaffe.org/
■JVM(JavaVirtualMachine)cJavagw
JavaVM橐M的平台,把@平台加以硬w作,即materialized後,就是
Javachip。碚f,它就是一w真r的CPU,倘使我不需完全CPU}s的
O,一涌梢⑺co-processor,云云一恚筒豁要在x86或SunSparc
上用JavaVM砟M,而是间接把Javabytecode「jo」Javachip上绦小_@
就是新近SunQpicoJava的技g,然,S著各硬wS商的投进,引进更}
s的技g,但原t上^念是分歧的。
「模M」既然非真,然在效力上就^吃了,以是就常o人Java绦谐⒊
Y源的印象,其那是指VirtualMachine的效能。榱烁倪MJVM效能,利用S多
技g减速,个中最主要的莫如JIT(JustInTime)Compiler(及rg器,注重:
不要跟「即r」[realtime]弄混)cHotSpot的AdaptiveCompiler等dynamic
compilation技g。
JavaChip是OptimizedforJava的OOP、exption-handling、memory/garbage
collection的特uchip,而x86(即鹘yCPU)K]有C++所g的machine
code中的new/exception-handling/memoryallocation/late-binding作硬w增援
的最好化幼鳌
拜VLSI之n,memoryallocation和garabagecollection的幼骺山挥捎搀w
作。在modem或中,用以滴活比DQ的DSP(滴挥)chip而言
,有所^的bit-reverse(作FFT[疾速傅立~DQ]用的),倘使以一样平常x86碜
@幼鳎鸫a慢10倍以上。又如以往的浮c算,比整颠算慢了20~30倍
,但因有了浮c减速器的出F,浮c算的速率可檎颠算的1.3倍!
前述提到JVM以co-processor情势作的体例,能够⒖NazomiCommunica-
tions[2]公司的a品,他推出一套Java减速晶片,@代JA108的a品
iT2G/2.5G或3G的手C利用。不必要加b~外的w,只需⑦@JA208
IC植进原有系yO中,即可年夜幅提拔Java贸淌叫蔬_15至60倍。
[2]http://www.nazomi.com/
接著,P者在PentiumIII上作MS-Windows2000M行以下:(原始ac
machinecode的φ)
c++的virtaulmethodcalling:
┌──────────────────────────┐
│21:testx->setx(20);//testx是一指宋锛│
│──────────────────────────│
│00401091push00000014│
│00401093moveax,dwordptr[testx]│
│00401096moveax,dwordptr[eax]│
│00401098movecx,dwordptr[testx]│
│0040109bcalldwordptr[eax]│
└──────────────────────────┘
不算argument4指令
c的一样平常call:
┌───────────────────────────┐
│good()│
│───────────────────────────│
│0040109fcall@ILT+0(?good@@YAXH@Z)(00401000)│
│004010a4addesp,00000004│
└───────────────────────────┘
不算argument2指令
java的virtualcall:
┌───────────────────────────┐
│my.getData(33);│
│───────────────────────────│
│aload_2│
│bipush33│
│invokevirtual#9<Methodmy.getData(I)I>│
└───────────────────────────┘
不算argument2指令.
c++的constructor:
┌────────────────────────────┐
│test*testx=newtest();│
│────────────────────────────│
│00401056push00000008│
│00401058call??2@YAPAXI@Z(00401184)│
│0040105daddesp,00000004│
│00401060movdwordptr[ebp-0c],eax│
│00401063cmpdwordptr[ebp-0c],00000000│
│00401067jemain+00000030(0040107d)│
│0040106dmovecx,dwordptr[ebp-0c]│
│00401070call@ILT+15(??0test@@QAE@XZ)(0040100f)│
│00401075movdwordptr[testx],eax│
│00401078jmpmain+00000037(00401084)│
│0040107dmovdwordptr[testx],00000000│
└────────────────────────────┘
11指令
C++destructor:
┌───────────────────────────┐
│deletetestx;│
│───────────────────────────│
│004010a7moveax,dwordptr[testx]│
│004010aamovdwordptr[ebp-10],eax│
│004010admoveax,dwordptr[ebp-10]│
│004010b0movdwordptr[ebp-14],eax│
│004010b3moveax,dwordptr[ebp-14]│
│004010b6pusheax│
│004010b7call??3@YAXPAX@Z(00401194)│
│004010bcaddesp,00000004│
└───────────────────────────┘
8指令
java的constructor:
┌───────────────────────────┐
│mymy1=newmy();│
│───────────────────────────│
│new#2<Classmy>│
│invokenonvirtual#11<Methodmy.<init>()V>│
└───────────────────────────┘
2指令
由此可lF,B设置物件的操纵而言,Java一methodcall只需一
machinecode,但用x86相π枰4,@是Java在指令集用嬷苯又г隆
我@而易Java的一―─目标a很小,可p易置於Y源困顿的家O
中,再加上S多F成的APIs可M行呼唤、^承的利用,的程式a便可l]年夜
的力气。
■绦幸
JavaVM的中心是绦幸妫湫槟J揭噶罴亩x,JLS(JavaLanguage
Specification)了绦bytecode指令魇颤N幼鳎K未怎样
作,因檫@是作者的任。绦r期,绦幸嬉绦芯w(thread)的情势存在
,云云的绦芯w可直gbytecode或g接的透^JITCompiler懋a生nativecode
。绦幸佬bytecode中掏出opcodecoperant,依JLS绦邢
P幼鳎又偃∠乱opcode,直到method前往或是G出exception。@部分
P者不盘算提太多,因槭忻嬉呀有H多秀的晒⒖迹孔⒖迹
探一样平常性的JavaVM作C制:
1.《JavaVirtualMachine》OReilly出书
JonMeyer&TroyDwning
有中g本:《JavaMC器》,由Java嗤WO所g
2.《InsidetheJava2VirtualMachine》McGraw-Hill出书
BillVenners
假如X得上一本^於笼统,那Venners的@本很合您胃口,xr
搭配焦獾谢邮JavaApplet解f械JVM观点,作者的W[3]
相S富的Y料收拾。本m有中文翻g本,但烈建he花冤枉X,因橹`
百出。
[3]http://www.artima.com/insidejvm/resources/
W㈧肚度胧JVMO:
《深切嵌进式JavaMC器-InsideKVM》
胡岳(MangoHu)
乎是世面上独一本探JavaKVM作的拇_是相F的⒖肌2贿^
,必要寄望的是,作者间接挖出KVM的原始程式a,是不是^充实授啵档
商讨。
■JavaVM效能探
今朝商IJavaVM效能最凸起的a品是BEA的JRockit[4]。JRockit次要
server-side米隽撕芏喔倪M,K且Intelf助IA32cIA64平台的最好化,
於是,在多benchmark上(SPECjbb和SPECjAppServer)上,JRockitbbI先
群雄。BEA是一家引IJ2EE技g的分量S商,在EnterpriseI域除越的技
g外,然要有健高效能的JavaVM,於是BEA就I下JRockit了,在S多高A
枚伎梢到JRockitVM的E。BEAW站上有篇由JoakimDahlstedt坦P的文
章,U述JavaVM的效能表F其能够冲破S多人眼R的:[Java-ASlow
Language?ItDependsonWhatYoureTalkingAbout][5]。
[4]http://www.jrockit.com/
[5]http://dev2dev.bea.com/products/wljrockit81/articles/Dahlstedt.jsp
JoakimDahlstedt的眍^可不小,是JRockitVM的次要O者,F任BEASystem
e^JavaRuntimeGroup的技gL,@篇文章K非老王u瓜,相反的,Joakim要
我明t,uJavaVM"benchmark"(效能u比)的体例必要{整,次要是基於以
下:
1.一样平常的benchmark比^HH是micro-benchmarklevel,不克不及推V到system-
level。
2.waI_l体例l生了很年夜的化,大批利用classlibrary、framework、
Applicationserver,以致Webservices。征引f的benchmarkH能ζ渲
esoftwarestack,s不克不及M行system-level的周全剖析,云云的权衡本
身就有}。
3.JavaVM自己的DynamicOptimization,可依钫的profiling{整
元件,使其π苓M行重M。
4.最後,新的CPU架,像是IntelEPIC大概更m合於DynamicOptimization
,而非鹘ystaticcompiler。在EPIC的架下,compilerπ艿挠绊相
年夜,compiler有任x衿叫刑淼闹噶罴窍鹘yPentium引进自
的out-of-ordery序绦兄г@意味著,w安排了EPIC的效能,@
staticcompiler是倒霉的,因H能bytecode获得流动的yc符,s
未能φprofiling作。
Joakim的Yo予我很好的l:
"Inconclusion,...,butIhopeIveconvincedyouthatusingruntime
systemslikeSunMicrosystemsHotSpotorBEAWebLogicJRockitJava
isnotsloworinefficient,andthattheperformanceofalarge-scale
systembuiltwithJavamaybesuperiortothatofthesamesystem
builtusingC."
IBM的JDK曾一度是最好功能的JavaVM,但SunJDK1.4的功能已cIBMJDK
1.3相,其server版裼酶eO的JIT和GC(GarbageCollection)技g,尤
其是SMP的锰峁┳钸m合硬w架c多绦芯w淼GC。
在另外一方面,IBM炔康JalapenoJVM研讨[6]的功效以OpenSource授
噌出的JikesRVM[7],供应一yS多JITcGC等技gc演算法的
考作平台。IBMRearchJikesRVM作JIT方面的一researchinfrastru-
cture,在W站上_列了相S富的文可⒖。P者⒖剂JikesRVM的研讨偏向
,JJITCompilerl展菘闪谐鲆韵拢
1.似於Hotspot[8]整合baseinterpreter、profiling,和adaptive
compiler三N技g的途。
2.Bprofiling技g,蔚counter-basedalgorithmM化到
performancemonitoringevent。
3.渺oBcompiler中更aggressive的g技g(JITCompiler而言,
grg已经是主要}),a生最好化原生a(nativecode)。
4.inter-procedural剖析,比方escapeanalysis能够removesynchro-
nization和施stackallocation。
5.⒖Runtime所@得的Y(次要是metadata和dynamicallocation),a
生最好化原生a。
[6]http://www.research.ibm.com/jalapeno/
[7]http://www-124.ibm.com/developerworks/oss/jikesrvm/
[8]http://java.sun.com/products/hotspot/
接著,我砜纯Sun的Hotspot技g。提到Hotspot不克不及不提HenryMassalin
@位先,Henry的博士文在JavaGlossary的HotSpot的解[9]中被u
"themotherofallself-modifyingcode",同r,HotSpot也是"buildsheavily
onworkdoneinaPhDthesisbyHenryMassalin"。
[9]http://mindprod.com/jgloss/hotspot.html
Java最后的作是透^直g器(interpreter),但@K非意味Java必定被解g
行的。初期的JavaVM的_是一一指令的解g,因而效能O不睬想,於是引进了
JIT等PI技g,而HotSpot可f来世代的JIT。Sun官方文I指出,利用
HotSpot的JavaVM在Runtimer期已很y分辩Javabytecode是不是被JVM解
绦辛耍HotSpotH上是把Java的bytecodeg成原生a绦辛恕
H上,在HotSpotO中,有技g是相主要的,也就是所^dynamic
compilation和profiling。HotSpotbytecode的g,K非在程式绦星邦A先
g的(@N鹘y的体例相Χ苑Qstaticcompilation),相反的,是在程式
行^程中,以HotSpot冉ǖ木g器做B的g,初期的JIT(JustInTime)其
也是云云的观点,不^]有HotSpot淼萌嫘浴
那N,HotSpot是怎样BgJavabytecode呢tHotSpot裼靡高度性的
O,炔烤So了ProfileMonitor,iTO程式绦兄校喑淌狡沃惺褂玫
l率高寡,K依π阅苡绊的水平,托付於多少演算法怼HotSpot赌切
程式绦r效力影^年夜的程式a片断,特Qhotspot(特e以小,制止
cHotSpot搅浑),HotSpot@些片断Bg成原生a,同r,
profiling的Y果,@些原生aM行最好化,而进步绦行省O喾吹模绻
行l率^低的程式a片断,HotSpot就]需要花rg做Bg,只必要以直g器
行便可。
整w而,在HotSpot下,Javabytecode是以解g的体例被d进到JavaVM中,
可是HotSpot立即承┏淌酱a片断绦械B,@知个中π苡绊最年夜的
部分,透^Bgc最好化恚⒃a,於是,接下淼绦羞^程中便可@
得相水平的效能提N。我能够得知,HotSpotbytecode的绦杏幸韵氯N
理体例:
-直g(不Bg)
-部分Bg
-依profilingY果做Bgc最好化
至於程式哪部分只做直g、部分Bg,和哪部分做何N最好化恚t全程由
ProfileMonitorQ定。
裼dynamiccompilation鹘y的staticcompilation硎颤Nc呢?撇
_跨平台需求不,dynamiccompilation在S多方面越於鹘y的途,特e是
profiling的才能。^往staticcompilation很y精实念A知程式绦兄芯烤购翁
才是最必要最好化淼牟糠郑H能透^冉ǖtemplate斫micro-level的
最好化程式a。相反的,dynamiccompilation可@悉最真的profiling表F,
依枨B{整,@在日後砥髦uw化的l展荻裕@得主要,因
^往硬w的事情逐u移D到w碜觯compileroptimization的任就分外沈重了
,像是前述IntelEPIC架。
另外一典范的例子,Qmethodinlining。o是在C++或是Java中,呼唤
(invoke)method是很损耗系yY源的,系y必So堆B操纵,以切合A期的
callingconvention。於是,有人提出把底本必要做methodinvocation的恚
改用inline的体例,「嵌进」到底本呼唤的中央,云云一恚椭皇渭的循序
行,也不卸询B操纵。可是,methodinlining的体例C++cJava一的物
件蛘Z言碚f,g器很y有很好的作体例,因樾枰骖物件虻奶蒯纾
其是S持dynamicbinding性|。staticcompiler其能够把C++/Java中傩
privatecstatic的method做methodinlinng,可是一旦有overridden或
dynamicbindingr,staticcompilero法得知H上的绦r,就J氐牟
予施inlining。@y},刚好可被HotSpot一dynamiccompilation的O
水到渠成,因ProfilingMonitormethodinvocation的r能够把握,
然可精实牡弥Runtime中,RTTI(Run-TimeTypeIdentification)可f助
HotSpotmethodinlining,因而,在server-side眠@N重}M行某目
绦r,可@得H年夜的效能提N。
Sun的文I也指出,在某些r下,Java的贸淌缴踔量杀鹘y的C程式快。
以今朝l展而言,JITCompiler的本钱次要在於profilingcdynamiccompila-
tion身。幻想而言,@身本钱constantanttime,於是S多研讨文
相^提出,以作樾芨倪M。特uJITCompiler利用、精度不需很高的Java
Runtimeprofiling可⒖肌APortableSamplling-BasedProfilerforJava
VirtualMachines〉[10],文提出裼sampling的体例碜鼋品治觥6领
Dynamiccompilation的overhead能够用uM式最好化的体例p少,在Sun的
HotSpot白皮延性M的介B。
[10]http://www.stanford.edu/~jwhaley/papers/javagrande00.pdf
而言之,Java效能h}次要分以下用嫣接:
-一样平常性
VMcJITg的互印bytecodetoIRtranslation、IRtomachineIR
translation,和codegeneration/formatting
-c平台架oP(machine-independent)的最好化
CSE、loopinvariantcodemotion、inlining、speculativeinlining、
methodspecialization,和multiversioncode
-c平台架相P(machine-dependent)的最好化
Local/Globalregisterallocation、instructionselection、instruction
scheduling,和code/dataalignment
-JavaZ言用娴淖罴鸦
Rangecheckelimination、checkcast/instanceofremoval、typepropagation
、optimizationsenabledduetostrongtyping
-GarbageCollection
Precise/imprecise/copying/generational/incremental
-平行向量化(vectorization)
RISC事情站的平行碇噶睿蚴侨Intel提出的MMXCSSE指令集
■Linux平台的JavaVM
在初期的SunJavaVM作中,绦芯w的增援次要透^GreenThread的light-
weightthread作的,@能够_保JavaVM在|性的作I系y仍可无限度的
行w增援,但是,@е滦实牡吐洌竟不是间接利用作I系y的Multi-thread-
ingC制。
今朝SunLinuxJDK已用nativethread改^,而Linux的multi-threadded
才能在IBM等年夜S的投进改M,次要有以下煞N情势:
1.NGPT─NextGenerationPosixThreads
⒍Javathread映照(mapping)到少ckernaelthread
2.NPTL─NativePosixThreadLibrary
⒚Javathread映照(mapping)到一kernelthread,以最好化
kernelthread
个中,NGPT[11]是IBM的一OpenSource,衍生自GNUPth[12],
NGPT透^patchLinuxKernel2.4cglibc的体例硖峁┲гNPTLt是
LinuxKernel2.6中主要O,可㈤〈TheNativePOSIXThreadLibraryfor
Linux〉[13]c〈Linux:NativePOSIXThreadingLibrary(NPTL)〉[14]@煞
典文I。
[11]http://www-124.ibm.com/developerworks/oss/pthreads/
[12]http://www.gnu.org/software/pth/
[13]http://people.redhat.com/drepper/nptl-design.pdf
[14]http://kerneltrap.org/node/view/422
接下淼钠P者⒔榻B曾接|^的OpenSourceJavaVM作。
-Kaffe(http://www.kaffe.org/)
Kaffe算是@I域中老字的0福1996年TimWilkinson完成最后的架
至今已七年v史了。Kaffe一_始是TimWilkinson在英l展的clean-room
JavaVM作,所^cleanroom,就是在不⒖SunJDK作的条件下,自行_l另
一相容的作品,那r的Kaffe是BSD-like授喾绞结出的。1997年,Tim
WilkinsoncPeterMehlitz立一家W㈧JavaVM作的公司,Transvirtual
Technologies(TVT),乐成的把Kaffe商I化,那r候_始,Kaffe有版本
:一是GPL授嗟OpenSource作,也就是Kaffe.org,别的t是TVT炔
So的CustomEdition,奠基了OpenSourcec商Il展的典。
KaffeVMO的理念在於高度的移植才能和_放(clean-room作,不用受限於
Sun的l行授)l展,由於TransvirtualKaffe的乐成,S多以KaffeVM榛
A的研讨0赶嗬^提出,S多湫碌母拍羁山逵KaffeF。KaffeVM的移植能
力有多好呢?已C能增援70NN平台,乃至包括JIT引擎。
TransvirtualTechnologies在1997年景立以恚鸵恢被钴S於嵌进式b置的I域
,而在2000年_始更⑵溟_l的KaffeVM整合DebianLinux,O出一Q
PocketLinux的平台,其中心架就是Linux和KaffeVM(特QLanguageEngine
),下面跑的,可都是真r的Java程式。PocketLinux是相特别的操纵系
y,以GNUDebian/Linux橹骷,上跑KaffeVMc3rd-partyopensource
library的整合h境,槭殖盅b置供应WebBrowser、Synchronization、Media
Player,和peer-to-peer解Q计划,别的,PocketLinux另外一特c就是透^
XML把KaffecLinux系y服者M行包b,_l者只必要透^XML就能够呼唤系
y供应的功效。
管是κ殖盅b置,KaffeVM算是最靠近完全功效的JavaVM,乎能cJDK
1.2相容,也增援PersonalJava瘢恢гJ2ME的Profiles。KaffeVM
的定位不H是smallfootprintJavaVM,更是全功效的嵌进式JavaVM,藉此充实
l]Java在分离式h境的能力。
很不幸的,在2001年c2002年之g,Transvirtual公司面RO年夜的D。起首
是Kaffe.org的次要So者EdouardParmelan在2001年作古,年年末,Tim
Wilkinson,也就是Transvirtual的CEOQ定x_公司。面R技g人TcY金的瞬
g充足,PeterMehlitz^任CEO後,Q定放OpenSourcel展路,改榧
粹的商I公司,於是,PocketLinux从头定名XOE,K且不再OpenSource,
Kaffe.orgDr成o人IB的孤海nD於Kaffe1.0.6的版本。但是,Peter
Mehlitz的e舆是挽救不了公司的r。
在Transvirtual遣散前夜,T工JimPick<jim@kaffe.org>在March12,2002
公布⒔邮志SoKaffe.org,K且⒅铝M行KaffeCustomEdition(也QKaffe
Pro)cOpenSource版本的整合,呼n_l者f助下release,也就是1.0.7
的出F。2002年中,TransvirtualY束I,可是不料味著Kaffe的]落,相反
的,在JimPick的I拢Kaffe.org乐成的@得更生,K且c其他Opensource
javaVM0腹蚕黹_lY源,比方GNUClasspathcGCJ。
停止昔日,S多分量的贸淌揭呀可在KaffeVM作了,比方JBoss、Tomcat、
Jetty,和EclipseIDE。
-Japhar(http://www.japhar.org/)
Japher作年夜部分的JDK1.1特徵,但不包括JITCompiler。自June19,2002
出0.11版後,就]有l展了,底本的_l者DQ到GNUClasspath0浮
-GNUClasspath(http://www.classpath.org)
l起於1998年的GNUClasspath在昔日已成樵S多OpenSourceJavaVM0
的省GNUClasspath事上K非JavaVM,而是供应JavaVM所必要的API
作,GNUClasspath的位置之於JavaVM,比如libc之於C程式。在2000年前
,GNUClasspath一_始(0.00版)只增援Japhar,K且_l相t乎统一
rg,RedHat/Cygnusl起GCJ(GCCforJava)的0福S多_l者的勉力_始
M行整合。S後MarkWielaard接任So者的重担後,GNUClasspath的近成熟
,Classpath::JVM[13]有份今朝窦{GNUClasspath功效的0盖巍
[13]http://www.gnu.org/software/classpath/stories.html
-GNUGCJ(GCCforJava,http://gcc.gnu.org/java/)
-ORP(OpenRuntimePlatform,http://orp.sourceforge.net/)
-Wonka(http://www.acunia.com/wonka/)
-IBMJikesRVM(http://www-124.ibm.com/developerworks/oss/jikesrvm/)
IBMJikesRVM衍生是炔康难芯坑,Jalapeno。Jalapeno是建於AIX/PowerPC
、Linux/PowerPC、OSX/PowerPC,和Linux/IA-32等平台的性JavaVM
作,後,IBM炔JalapenoJVM研讨的功效以OpenSource授噌出,
K建立的JikesRVM,供应一yS多JITcGC等技gc演算法的⒖
作平台。JikesRVM在其架O上一向是湟桓瘢鹘y的JavaVM作上,中心
次要仍以C/C++橹鳎JikesRVM的中心除平台相依的部格外,其他^年夜多
刀家JavaZ言作,也就是f,JikesRVM能够是self-contained的,正如
FAQ所说起的:
"JikesRVMisuniqueinthatitisthefirstself-bootstrappedvirtual
machinewrittenentirelyintheJavaprogramminglanguage,i.e.,its
Javacoderunsonitself,withoutrequiringasecondvirtualmachine."
在l展后期,JikesRVM仍利用IBM炔康coreJavaAPIsclasslibrary,@部
分K非OpenSource的,@也使人病IBM的半{子_放B度。但自JikesRVM
2.2.1_始(April7,2003),JikesRVM可间接利用GNUClasspath的功效,@也
是fD一完整OpenSource的JavaVM研讨。但是,由於JikesRVM^年夜
部分的中心在建r,仍必要一JavaRuntime,以是_l者必要安bSunJDK
一的非OpenSourceJavaVM,但比来K於有所改^。自2.3.2版(March17,
2004)_始,我可使用GPL授嗟KaffeVM作JikesRVM的boot-straping
JavaVM,@是OpenSourceJavaVM另外一功效累e的展现,可⒖JikesRVM
UserGuide[14]。
[14]http://www-124.ibm.com/developerworks/oss/jikesrvm/userguide/HTML/
Bootstrapping_with_Kaffe.html
-JamVm(http://jamvm.sourceforge.net/)
-JCVM(http://jcvm.sourceforge.net/)
(...未完...)
再举这样一个例子:如果你想对一个数字取绝对值,你会怎么做呢?java的做法是intc=Math.abs(-166);而ruby的做法是:c=-166.abs。呵呵,这就看出了java与ruby的区别。 |
|