JVM: platform independent vs. performance dependenV

JVM: platform independent vs. performance dependenV Ruben Pinilla, Marisa Gil Computer Architecture Department, Technical University o f Catalonia c/Jordi Girona, 1-3, Campus Nord, 08034 Barcelona, Spain e-mail: {rpinilla, marisa}@ac.upc.es

Abstract Nowadays Java technology has become an important reference to application developers. The great acceptance from software developer's community is mainly based on its platform independence execution environment. In this paper, we analyze the degree of dependence between the Java Virtual Machine (JVM) and the underlying platform. We have observed that the Sun JVM (Java 2 SDK 1.2.2-006) API is independent from programmer's point of view, but offers different behaviour depending on the target HPI (Host Porting Interface) implementation, being a possible cause of incorrect program execution. This fact can be solved implementing a HPI that could manage scheduling entities provided by an operating system (or a threads library) performing a uniform behaviour independently of the target operating system.

Keywords: Multithreaded, JVM, user threads, kernel threads, scheduling, concurrency, Java threads.

1.

INTRODUCTION

These last years Java has came up as a valuable technology for building concurrent applications. Its great acceptance, from software developer's community, is mainly based on its platform independence execution environment and its built-in language facility to write concurrent Java programs. Such independence is made by isolating the platform characteristics in various independence layers (see [2] and [8]). This design has to be studied to see the affectation in performance due to the abstraction degree and the relationship between the platform independence and the behaviour of a concrete platform. In this paper, we show the degree of dependence between the Java Virtual Machine (JVM) and the underlying platform. We have chosen the Sun's JVM implementation (Java 2 SDK version 1.2.2-006) to analyse some ported versions (Linux, Solaris, and Win32) to stand out possible differences in the execution of a Java application.

' This work has been supported by the Ministry of Science and Technology of Spain and by the European Union (FEDER) under contract TIC2001-0995-C02-01. The Itanium based computers are a HP/Intel grant to the Computer Architecture Department.

44

The rest of the document is structured as follows: section 2 presents the HPI layer and a study about some differences among the platforms. Section 3 shows some experimental results and section 4 concludes the paper setting out some future work.

2. H P I L A Y E R One of the goals of Sun's JVM implementation is to make Java an independent architecture [5] from the underlying platform: For this purpose, it uses an interface called HPI (Host Porting Interface) to develop an abstraction layer from the target operating system. To understand the existing dependence between HPI implementations across different platforms, we will see the implementation of some example HPI calls. For this study, we define in Table 2-1 some thread attributes that explains its main characteristics:

Contention Scope

Detach State

Inherit Scheduling Priority Scheduling Policy Stack Address Stack Size

Tells whether a thread is bound (global scheduling) or unbound (local scheduling) to a kernel scheduling entity. Determines whether the thread will be joinable from another thread and whether the thread can return exit status. If thread is detached then its resources and exit code will be discarded. By the other hand, if a thread is joinable, its resources and exit code will be retained until the thread is joined by another thread. Specifies whether the thread inherits its scheduling policy from its parent or the scheduling policy is given on creation time. Thread priority. Express the scheduling policy used with a thread. Thread stack starting address. Thread stack size. Table 2-1. Thread attributes definition.

We have chosen a couple of HPI calls to illustrate the difference between the HPI implementations in Linux, Win32 and Solaris. The functions are s y s T h r e a d C r e a t e and sysThreadSetPriority. In these functions, the s y s t h r e a d _ t type has reference to a thread offered by the platform (i.e., Pthreads, Win32 threads, Solaris threads, etc.) In Table 2-2 we describe the sysThreadCreate function:

int sysThreadCreate (sys thread t **tidP, long ss, void (*start)(void *), void *arg)

Creaies a thread in tidP, With a stack of ss bytes, withan associated code referenced by start (a pointer to a procedure with a pointer as parameter) passing arg as argument. The thread is created in suspended mode. Function returns SYS OK if the thread has been created successfully, otherwise an integer errorcode is returned. Table 2-2. sysThreadCreate description.

45

Every system defines its thread creation attributes depending on the API provided by the operating system or threads library. These attributes are described in the following table:

By de~ult, PTHREAD

~' ~,star&~&~m -2"arg; ......

tid~>Sta~e

~!'~L". err

•?i',

i -.. .L - "

= SHSPENDED;

& ":sere."init ( &t fd~>sem

" " " e r r 1:= :sere- i n i ~ t ~ t i d ? > s :syiAssert".~gr{ .; . 0):';.

/-;

o

".. ~ ".'

" " "

'-"

at£r

' 0 ; 0) ;,

~:_:

''-' err ~=tPthread

N o t i m p l e m e n t e d in - ;' : " '-";1'.~ ' . -:'i| Linux. W e can't specify -'." :S . ~ / ~ !"L. I the stack size o f & .-O ~, 0 ) ; i : . ~ . - : - ]

:'" ' :-. "

thread,

':

-'"sem ~;'ait:(&tid~>sem ~em:-destroY

-, ::

-

~,"~;.: e~.r

'::: ~.,- if

.:~::-": . { : ". " " "

(,&tid->sem,

reads, to

~'~np-s.uspend i£id~, ~ ~

.(~f~-S¥SOK).:,(

:

to~sus.pegd)-}

. %. ":

:

*-).tid:)[~:-....:

Pthreadcreation. , ~ ':. . . . . . . . I

':.~' ?:-: I

~uspenas

. ..

,-~.

Ii I

me m r e a o

using

P O S t X s e m a p h o r e s (self s u s p e n d )

:-", :,'~ :-l orpthread

e:rr = : s e n ~ p o s t ~ & t ~ a - > ~ e m ~ u s p e _ n d g d ) - t

48

(void

susp~f~d) £I . . . . . . .

~'- ._~ff~

.....'.-' .:/*" Unblock-tAe .thread now ; t . h a - t - ~ t ) ," ".

_.~,:-. : . ,',~

:t" ' .. '.~i.~..: .~.' .Y%

&a~-£r; ,. ~:tA:rt,

.... ' . . . 1 .ready'

~"~" .... : ,".' " "/~'.~uspend'" ~ h e t ] l ~ e ~ d - * / ~ _ . .

'/:/'..-;"

,

Th~, .~.hi'ead w i l ~ b~oGk...Wai.ti~9: :t d: he:s:Usp'en~e..d-k/,

~reate(&tid->sYs

) i , .... . . . : : . : . . " ".

..~',,'~::.,: - " ....1'

" , - :,,.'" : : .::--"-,-i" :~. ,-;

.setsc0pe.(&attr~PPTHREADi~SCOPE.~SYST~.~.)

[ h e ~hread.

".1.-'~"/'~"G~eat9

.

...... ~" "~:;"'~ .J~~-~

: ~±fdef. P o s ~ x : . T H ~ E A D . A T T R STACKSI ZE i . ,:: - ~: " ~ , ' . ? , . i " :. ] " " ' " : l ~ t h ~ e a ~ att-r 'sdt~tacksize(&&ttr, stack..:size) ; : ' -'-'" .~ ..

~i:'~"~:- " -i,pthread

, ,

-.,~."i ' " .... !: :" "

:, : . i. .:." ,< .," -.: ~'~ " ': ' " " ~ ' " " "

era-susPende,d,

"'--'" ' i .

. %?./."

t -=" ,FALSE.;

ready--to- s Uspend~

:.~:rhzlea'd~attr~b.uteS"*/

" :- ' ":~, " . " e t . r

~ro£d

kill.

h~als been suspended * / '.. ,.:" ."..~-~:.. _:~..t . : : . /

Table 2-$. Linux source code of sysThreadCreate.

49

•

.whiie ('tid'>ntCohd.sta~ .!=,N E W T H R E E 3 PJ~QUESTBD, S0SPEND) .. : : - ~' :#i-:i::ii/'.i!.' ' " p.thread-cond~wai~(&tidigntc~nd,&, &t:id->n~.e6nd;.m); : ; • .,...' .: .... ~ "...

-t '-rip suspend(ti.d~>syS ~ h r ~ e a d ) ; - ~

" ,',

i,,. t i d ~ > n t c o n d is~ate = - N E W T H R E A D - S U S P E N D E D / i [. '~. " p t h r e a d i c o n d : ~:±gnal-(i&£i.d-L>t/~Cond, c)'>;, , p.tl%read-mutexLvn~0~ck~ (.&t!&d~'mntcond ~.m);

',: ,..

.....

/"1 Thread suspend calling

: (' ," . "i I '." ':.: :~') .... ' I t h r ,~:!~...i . '-::.. -I

I" I[

suspend.

" /*:i C r e ~ ' 8 : ~ e ~ n ~ - e a d - ~ / : ",, . : . : ',< :,., ,:! -, ii,,i ..... ' , : ' I Solaris thread creation " , 'er.~ i . £ h r : c ~ B e a t e . ( N g L L , , , ' s t a c k L s i z e , . ~Start" (void:*)~tildi ' ,-I ~".,.. :"~ " i, . ' .... '., • THR ~SU'SPENDEDI THRiDETACH~DI :' :~', " . "I " " in S U S P E N D E D ' ' • " :7..-: :" .: ( p r 0 f i l e r o n ? ,THR BOUND--:, O,)'j./" stale. • ;;~",' : " " . " " - " ' ' ,. &tLd~>sys-~h~eadJ;i ~: " .: i, .... ." ,',,' . .. . . . . . . . . . : :.~ #endff : / ~ ~ J S E PTHREA[gS"*i]": i"- ' ":-;... t::;...!.:../.~:: . ' i:?. , ' . : ,:. ' ' i ..t.. ' . ",:" "

> :::>>I

.:: " ~ ~rr:~==..E~z~)~(:,,; '- :.' .-': , : .":':~ :~-:... : ,~:~r.. L SYS ~ORESbUiZqE; '-:, ii~ Wi.tl; "be : t ~ e a ~ d .

: < .~",'~:;:"~(

,-:"",'i .'-'~.e r r ~='''S¥S

. :.:.:.~V.:.,:"!-:.:::!.

.',:..'",:' .:?" :i .'( :' " "k. '.:.'.~':?-(~'

'.,." : - , 7 . . . . .'

-~'-~- ': ':!

::

S,~'SL.~O.~¢~. ~:~:" :b~'~ :: ;

"'

!.~:

• y" ii' :?'::~:;: ?,: " . :

~J::',','" ~

,i,i .:..r.,..,,)i:,~i~''-

sysThreadCreate.

I

.,

.

-

:

.~:-"/?,,.!..

-

'.start

proc

=.,proc,

'

~ .... " '

*"

Sta~t..the

queueInse'rt return } _~"

-

"

'

':" "

"-"

~ CreateEvent(NHLL,..T:RUE,.

~:

, - ~i . : ~ n,ew ~ h r e a d . .... -" " .

(tid).;

"

SYS-;OK; - " _ .~. .... .:?. -:

--

"

"

i"'i!

FAL-$E,' NULL)';

. " "'° . I W i n 3 2 t h r e a d c r e a t i o n i n s u S P E N D E D ~ ° . ' '.: :! ~*~te ~/ ~:. ~ . " " : I . . . . . tidi>h'a~dl& ~ ('HANDLE)-begi~threadex'(~UL~ stack size, . Start,!{ t i d , " '. • '" ' ~ ""i.:,..- - .'-[" ~.." " CREATE SUSP#NDED,.-.~ti:d->iS).{ i f .'(tid-~>~andle = = O) {. . ~., ~, . .. -":, ...~. 't i . - . ...',." " : retuzn'~ S Y S N Q R E S O U . R C E ~ /~ .wii_~ be treated'as thoUgH ,SY:~,NOb]EM~/ /~

"

-; -t ..- ;..,

(sys' . t h r e a d _ t ,**tidV;. l o n g S.£ac~K_.fize', :i ,.". ' """'/ ' ~ : ," '-. void (*.groh).(void. ~):, v o i d * a r g ) ' " . " z. . " . '. ..:.~ . ,T

~id~>interrupt:"ekY~nt "

,,~ ",,

./

~/~,

"-

' .

.

.

..... ]"- • '." : : " t"ii:3 . :.:. ....: . . . . ~ :

T a b l e 2-7. Win32 source code o f

50

.

.

" " ....

sysThreadCreate.

'

". :..,iS

"":

~., ~, ..--.~

sysThreadSetPriority implementation

Table 2-8. Linux source code of

sysThreadSetPriority.

Table 2-9. Solaris source code of

sysThreadSetPriority.

51

case

"

-[,case • ~_ - ' .'.. -..

-3:

c a s e

5: " :priority

ca s e

6::

.case

priority

" _ .

"

;

-

,,.'-

.

default: ~ " "

" , :~r.t~*rn:

.

,.

"

..".'"'~:; ;? " " ". ..:" " =' %HI~EAD~_pRIORITY_NORt~AL; : :, 7:~ ~ .

- ~

°':.

=_-.THREAD ' PRIORITY

7 ,

..."~

Seg~hreadEri'ority

. . .

,~-

..

[:.

.

"_

-

.

. -~ .' '-";:, : '-. ( . '-( " :-' " [ : :

ABQVE" NORMAL;

HIGHESTJ

p~igrity-=~'~HRE~o2:PRiORITY

break/;.

-

~,

.

.

• ...:

.

~-.. -

•

. . .•. . -./,

.',[

"

.

,~.

,

'

.:.-;~..,:" '~ ~. ; :

.

,~

""

-

. .':"

" . . . . . . " ""

.(- fi ..(i "Z

," 7':7"',,.:..

"

I

....

[ Setting the new priority value in VVin32

(tid->handle,•::pZ'iOr!ty~

":? S Y S

OK: ~ SYS iE~]i'[::;:

Table 2-10. Win32 source code of s y s T h r e a d S e t P r i o r i t y At this point, think we about an application that runs using several threads with different priorities. What behaviour we can expect of the execution of this application on the platforms we have seen? According to Java specifications [ 11 ], a Java program is independent of the execution platform, but our Java 2 SDK source code analysis seems that exists some dependence between the HPI level and the target platform.

3. E X P E R I M E N T S To see the existing dependence degree in the HPI implementation and the underlying platform, we have selected an application, represented in Figure 3-1. In this application, the main thread creates 4 threads with different priorities and waits for the end o f all, that are running concurrently.

JOIN

Figure 3-1. Fork-join execution model to study. In Figure 3-2 we observe the application behaviour in different platforms:

52

[

WK[O] Prk:dty(l) i WK[~] Priority(2)

WKI3] 5 tu.

I~ t ~

WKt21'r~t'~s) I WKFI ..ray,.)I

| ...........

t..- ~mu.~_J

WK[2] 10 flu.

WK[ll 18 tu.

Processor

P Green Threads

W1K[0] 5 t,u.

WK[0I Z0 L ~

WK[ll 10Lu.

WK[23 18Lu.

W~pltgtu. I I

WY,,[3] 20 t.u.

Processor

Time wKI2l Ir t.. WKIOIl a tu.

Processor

P

1 (~) Native Threads. Solaris

( ~ Native Threads - Linux

Time

"lirne

WK[0] 10 t.u.

VWp110tu. WKI2] ,~

.... Proc4lssor

I

'

I

Processor 0

I

I

I

I

|']

___~

WKp] 9t.u, / Processor 0 Processor 1

1 I

(~) Native Threads. Win32

I WKt31St~, ~nqal ' s,.u. Processor I

VvKll120tu. WK[O| 19t~' t

I

I

"~ ~[319luu.

' (~) Native Threads - L i n u x . Multiprocessor

Time

wv.lol ,1, ,o tu. I

.....

t J ' :C;si'u" | . W~,]10~~LU.

~me

,, Z0tal.

I

~ _ . . - - W K [ I ] 10 t.u.

Pr~s,.~r

I i I l r

Native Threads. Win32. Multiprocessor

Tim:

@ Native Threads- LJnux. itanlum* (IA64) "C./4m/c VM (butter

~i

L30.J2RE 1.301BMIA.64UnUXtxdlddnx6413~.2001080~(JIT~mble~)

Figure 3-2. Results of different platforms executions.

As we can see in Figure 3-2, the application execution behaves differently. We see that CPU processor time is shared in a round-robin way in graphs B and C, because of the selected POSIX threads scheduling policy (SCHED OTHER)in Linux. In these cases, Java threads priority is obviated always being 0, so the kernel scheduler is the responsible of schedule them with its dynamic priority (time sharing). On the other hand, in graphs F and G it behaves as source code predicts, that is, two Java threads with different priority behaves as they have the same priority due to the HPI - Win32 priority mapping. There are some odd situations (see graphs D and E) where their executions follow a FIFO scheduling. Apparently, the execution of graph E should behave as Java specification describes, because the priority mapping and the scheduling algorithm are correct, but in this results don't go with theory. Graph D depicts the execution over an Itanium architecture (IA64 with a different JVM version) running Linux [3] that behaves completely different than graphs B and C. We wanted to run the IA64 test with the same JVM version, but it is not ported to IA64 Linux. So, we chosed the IBM's JVM to compare their results. We have only obtained the expected results in graph A, where the application execution behaves as Java specification tells. Java threads are scheduled with a preemptive priority scheduling algorithm. Thus, the first executed thread is the most priority one (priority 4) and the last, the one with less priority (priority 1). Both Green Threads for Linux and Solaris behaves equally. The results that we have achieved show that a user threads scheduling model seems to be a good solution to get a common behaviour across all the platforms and a way to implement a platform independent model of threads (as Green Threads do).

53

4. CONCLUSIONS AND FUTURE W O R K With this study we have examined the degree of dependence that exists between the JVM implementation and the target operating system. Using a test application that has been ran in different Java platforms, we have observed singular behaviour depending on the HPI implementation. Despite JVM offers an API that performs independent, the JVM's HPI level implementation makes real the possibility that the same program could perform differently depending on the execution platform. Therefore, the existence of a HPI which semantics of its operations vary depending on the implementation, for a target operating system, it's a fact that causes the Java platform don't be so independent. To correct this situation, we propose an alternative implementation of HPI (preserving the same API) that would make it more independent from the underlying operating system. The new HPI would have a uniform scheduling policy that manages the scheduling entities equally across any target platform. So, in this way we would reduce the differences observed in this work. This goal would be reached implementing a threads library managed with a priority scheduling. It also would be interesting that it would support a distinct one-to-many threads model to take advantage of multiprocessor architectures. Actually, we are developing at the Computer Architecture Department a user level threads library (ULT library) that will be used to develop a platform independent HPI layer. In the next figure we present the resulting structure of the HPI, referring only to the threads execution model:

HPI calls

HPI

OS

Figure 4-1. HPI-ULT threads execution model.

54

So R E F E R E N C E S [1] Allen Holub (1998) Programming Java threads in the real world

JavaWorld, September- October http://www.javaworld.com/javaworld/jw-09-1998/jw-09-threads p.html http://www.javaworld.com/javaworld/jw-10-1998/jw- 10-toobox p.html

[2] Bill Venders (1999) Inside The Java Virtual Machine, 2ndEdition

McGraw-Hill Professional Publishing, December ISBN: 0-07-135093-4 http://www.artima.com/insidejvm/blurb.html

[3] David Mosberger and St6phane Eranian (200 I) ia-64 Linux®kernel design and implementation

Copyright © 2002 Hewlett-Packard Company Pretince Hall PTR, November 2001 ISBN: 0-13-061014-3 http://www.lia64.org/book/ [4] Doug Lea (1999) Concurrent Programming in Javd m2"d Edition: Design Principles and Patterns (The Java tmSeries)

Addison-Wesley Pub Co, November ISBN: 0-20-131009-0 http://gee.cs.oswego.edu/dl/cpj/index.html

[5] Douglas Kramer, Bill Joy and David Spenhoff (1996) The Java TM Platform (a white paper)

Copyright © 1996, 1999 Sun Microsystems, Inc., May http://java.sun.com/docs/white/index.html [6] Mark Secrist and Laura Smyrl (2000) Threads and the Java TM virtual machine

AppDev ATC, December. Copyright © 1994, 2002 Hewlett-Packard Company. http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,390,00.html [7] Per Brinch Hansen (1999) Java's insecure parallelism

ACM SIGPLAN Notices, v.34 n.4, p.38-45, April

[8] Ruben Pinilla, Marisa Gil (2003) Concurrencia en la JVM

Technical Report UPC-DAC-2003-5, Computer Architecture Department, Technical University of Catalonia http://www.ac.upc.es/recerca/reports/DAC/2OO3/index,en.html#UPC-DAC-2003-5

[9] Sun Microsystems, Inc. (1997) Java Native Interface Specification

Copyright © 1996, 1997 Sun Microsystems, Inc.

55

http://java.sun.com/products/jdk/1.2/docs/guide/jni/index.html http://java.sun.com/products/jdk/1.2/docs/guide/jni/spec/jniTOC.doc.html [10] Thomas W. Christopher and George K. Thiruvathukal (2001) High-Performance Java Platform Computing: Multithreaded and Networked Programming Copyright © 2001 Pretince Hall PTR Pretince Hall PTR, February ISBN: 0-13-016164-0 [11] Tim Lindholm and Frank Yellin (1999) The Java TM Virtual Machine Specification, 2ndEdition Copyright © 1999 Sun Microsystems, Inc. http://java.sun.cora/

56