Field of the Invention

The present invention relates to multi-tenanted computin such as occurs in a cloud computing environment and/or in virtualisation environments.

Vaiious frameworks are known in which multi-tenanted computin can arise and these include hypervisor, virtual machine monitor, operating system containers, and multiple independent processes (or operating system tasks) on a shared operating system.

The present invention is particu arly concerned with reducing the consumption of the host's or "landlord's" computer assets by the multiple tenants. Such computer assets include memory, CPU user time, power consumption, and input output (I/O) bandwidth.

B ack ground of the Invention

Wake-on-LAN (WOL) is an Ethernet computer networking standard that allows a computer to be turned on or awakened by a network message,

The message is usually sent by a program executed on another computer on the same local area network. It is also possible to initiate the message from another network by using subnet directed broadcasts or a WOL gateway service. Equivalent terms include wake on WAN. remote wake-up, power on by L AN, power up by LAN, resume by LAN, resume on LAN and wake up on LAN. In case the computer being awakened is communicating via Wi-Fi, a supplementary standard called Wake on Wireless LAN (WoWLAN) also exists.

The WOL and WoWLAN standards are often supplemented by vendors to provide protocol- transparent on-demand services, for example in the Apple Bonjour wake-on- demand (Sleep Proxy) feature.

Ethernet connections, including home and work networks, wireless data networks and the internet itself, are based on packets of data sent between computers. Wake-on- LAN ("WOL") is implemented using a specially designed packet called a "magic packet", which is sent to the computer to be woken up. The magic packet contains the MAC address of the destination computer which is an identifying number built into each network interface card ("NIC") or other Etherne device in. a computer,. The MAC address enables each computer to be uniquely recognized and addressed on a network. Powered-down or turned off computers capable of Wake-on-LAN will contain network devices able t "listen" to incoming packets in a low-power mode while the system is powered down. If a magic packet is received that is directed to the device's MAC address, the NIC signals the computer's power supply or motherboard to initiate system wake-up, in much the same wa as operating the power on switch would do.

The magic packet is sent on the data link layer (layer 2 in the QSI model) and when sent, is broadcast to all attached devices on a given network, using the network. The IP-address (layer 3 in the QSI model) is not used for this activity .

It is a common misconception that because Wake-on-LAN is built upon broadcast technology it can only be used within the current network subnet. While this is generally the case, there are some exceptions, and Wake-on-LAN can operate across any network in practice, given appropriate configuration and hardware, including remote wake-up across the internet.

In order for Wake-on-LAN to work, parts of the network interface need to stay on. This consumes a small amount of standby power, which is much less than normal operating power. Disabling wake-o -LAN when not needed, can therefore very slightly reduce power consumption on. computers that are switched off but remain plugged into an energised power socket.

Typicall WOL is used in server environments by configuring the- host operating system of the server to shut down or power down the computer after periods of idleness, and rely thereafter on WOL to wake up that server. While wake-on-LAN has found success in server environments in that kind of role,, with the advent of virtualixation and cloud computing trends of the last 10 years, the wake-Ou-LAN technology has ceased to be relevant.

Specifically in multi-tenant cloud computing, where multiple independent and isolated applications are co-located on a single operating system. wake-on-LAN cannot.be used to passivate a single tenant when that tenant becomes idle. This is because there are normally one or more other tenants sharing the same computer system which may not be idle. As a result, WOL has ceased to be used in such environments.

Separately, in the era of multi-tenant cloud computing, such as PaaS, SaaS, and devops/dev-test environments, it is very common for half, or more, of all tenants (application ) within a multi-tenant server to be idle at any given moment. In

conventional multi-tenant computing environments, idle tenants or applications are not treated i any different manner to bus or active tenants or applications, so that the idle applications or tenants continue to occupy the same physical memory reservation and CPU reservation that the application or tenant would/does occupy when it is active or busy.

Idle tenants or applications in these multi-tenant cloud computing environments thus represent wasted computational capacity (such as wasted CPU reservations, wasted memory capacity, wasted I O bandwidth, etc), because any computational capacity reserved for idle tenants/application i by definition not available for use by other acti e tenants/applications .

The Genesis of the present invention is a desire to provide an efficient scheme to redirect some or ail of the reserved computational capacity of the idle tenants or applications to additional active/busy application or tenants without shutting down or effecting the service level agreement (SLA) of the now-idle tenants/applications . This idle computational capacity could therefore potentially be more profitably redirected to other active or busy tenants or applications, thereby reducing the overall quantity of computing capacity required by shared computer system(s) to operate plural tenants, S ummary of the In ven tio

In accordance wit a first aspect of the present invention there is disclosed a method of saving computer resources in a multi -tenanted computer environment in which a plurality of tenants operate within a single JAVA virtual machine, or equivalent, said method comprising the steps o :

(i) monitoring predetermined characteristics of the operation of each tenant;

(ii) upon said, predetermined characteristics achieving a first predetermined state, or crossing a first predetermined threshold, inactivating the corresponding tenant; and

(iii) upon said predetermined characteristics of an inactivated tenant achieving a second predetermined state, or crossing a second predetermined threshold, reactivating the tenant.

In accordance with a second aspect of the present invention there is disclosed a system for saving computer resources in a multi-tenanted computer environment in which a plurality of tenants operate within a single JAVA virtual machine, or equivalent, said system comprising:

a characteri tic monitor to monitor predetermined characteristics of the operation of each tenant;

an inactivating actuator connected to said characteristic monitor and operable to inactivate a tenant upon said monitored predetermined characteristics achieving a first predetermined state, or crossing a first predetermined threshold; and

a reawakening actuator connected to said characteristic monitor and operable to reactivate said inacti vated tenant upon said monitored predetermined c aracteristics achieving a second predetemiined state, or crossing a second predetermined threshold.

Brief Description of the Drawings

A preferred embodimen of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

Fig. 1 is a schematic representation of a prior aft multi-tenant computer system.

Fig, 2 is a schematic representation of a prior art JAVA Virtual Machine utilising the WARATEK (Registered Trade Mark) JAVA Virtual Machine, Fig. 3 is a schematic representation illustrating how a multi-tenant framework of Fig. 1. or a multi-tenant JVM of Fig. 2, is modified in accordance with a preferred embodiment of the present invention.

Fig. 4 is a schematic representatio illustrating a further modification to the arrangement of Fig. 3,

Fig. 5 is a flowchart illustrating the preferred monitoring facility steps.

Fig. 6 is a flowchart illustrating the preferred passivating steps.

Fig. 7 is a flowchart illustrating the preferred awakening steps,

Fig. 8 is a schematic representation of the monitoring arrangement of the preferred embodiment, and

Fig. 9 is a schematic representation of the class diagram of the modified comp u ter operation .

Detailed Description

The preferred embodiment of the present invention disclose an alternative

arrangement to wake-on-LAN which is designed specifically for multi-tenant cloud computing and virtual ized server environments. This new -arrangement identifies which tenants or applications of a multi-tenant server are idle, and when a tenant or application is identified as idle, it transparently reduces the reserved computational capacity footprint of the application or tenant without shutting down the tenancy or exiting the application- Fur ertnore, the near-instantaneous resumption of the idle tenant or application is achieved when some external event is detected which relates to the passivated tenant or application.

A prior art multi-tenant computer system comprising a single server computer is shown in Fig. 1. This multi-tenant computer system is operated with one of several multi-tenant frameworks 102 such as but not iimited to a hypervisor, virtual machine monitor, operating system containers, or multiple independent processes (or multiple independent tasks) on a shared operating system. Regardless of the type of multi- tenant framework used, a plurality of tenant containers 103 A, 103B... 103N are operated by the muititenant frame-work 102, and each tenant container 103 operates an isolated application 1.04 A, 104B... I04N which can be independent started, slopped, shutdown, and destroyed. Each tenant container 103 and corresponding application 104 can belong to a corresponding unique owner, or all the tenants or applications can be owned by a single entity, or some combination thereof. Hovyever, regardless of the ownership arrangements, the multi-tenant framework .102 operates each tenant container 103 and corresponding application 104 in an isolated and independent fashion.

I a second prior art arrangement, the multi-tenant framework is a multi-tenant Java Virtual Machine such as the WARATE JAVA Virtual Machine as shown in Fig 2. In this multi-tenant framework, multiple independent tenant applications 204A, 205 ^' B...204N are each operated in isolated Java Virtual Containers (] VCs) 203 A, 203B ...203 N, which can be independently started, stopped, shutdown, and destroyed. Other multi-tenant JVMs (such as for example the IBM .1 JVM, and the Sun

Microsystem MV JVM) will be known t those skilled in the computing arts, and the present invention can be applied to all such multi-tenant JVMs mutatis mutandis.

As seen in Fig 3, in accordance with a first embodiment of the present invention a monitoring facility 301 is provided in the multi-tenant framework .software 102 which observes one or more "application activity indicators" for each tenant container 103 and its corresponding tenant application 104. One example of an '"applicatio activity indicator" can be reading from, or writing to, transport control protocol (TCP) or user datagram protocol (UDP) sockets undertaken by the tenant container 103 or its corresponding application 104, Other "application activity indicators" for which similar observations of a tenant-container's and/or tenant-application' s activity can be made include reading from, or writing to, files on a file system. Additional

"application activity indicators' ^' include CPU activit such as by observing or monitoring "user time" of one or more of the threads of a tenant-container and/or tenant application operating within a Linux operating system (or other equivalent means on other operating systems).

It is not necessary for the monitoring facility 301 to be provided as part of the multi- tenant framework 102. In other arrangements, the monitorin facility 301 can be provided in the management software which manages the multi-tenant server 101 or the multi-tenant framework software 102. In yet other arrangements, the monitoring facility 301 can be operated as a separate tenant container 103 of the multitenant framework software 1 2, such as when the monitoring facility 301 is operated as an independent operating system task (process) on top of a shared operating system. It is not necessary for monitoring facility 301 to be substantiall operated on the same server computer 1.01 as multi-tenant framework .102, but that is desirable for performance or efficienc reaso s.

Fig 4 shows how i a second embodiment, configuration settings or properties 401 fo the monitor facility 301 can be specified by an administrator of the multi-tenant computer system 10.1, or alternatively by the administrator of one or more of the tenant containers 103 or tenant applications 104, by means of configuration file(s) or configuration settmg(s) stored on hard disks, databases, or other storage means. These configuration details or properties 401 optionally specify thresholds of

inactivity/idleness (such as elapsed periods of time without at least a certain amount of activity) which the monitoring facility 301 has to wait for, or detect, before passivating the tenant 103 and its corresponding application 104. In different embodiments, the configuration details 401 that specify the duration of the idleness period to wait for can be variable (such as, for example, 5 minutes, or 5 seconds, or any other time interval), and be in additio to the type of tenant or application activity which is to be monitored (eg, TCP reading/writing, and/or TJDP reading/writing, and/or File reading writing, and/or increasing CPU user time, or any combination thereof). A range of potenti ll desirable configuration, properties in accordance with the description herein will be apparent to those skilled in the computing arts beyond those described here.

Fig 5 shows the monitoring steps of one embodiment of a monitoring facility 301 for monitoring a single tenant-container 103 and its corresponding tenant-application 104. Fo multiple tenant-containers and/or multiple tenant-applications, the steps of Fig 5 are repeated for each tenant-container and/or te ant-application which i to be

operated in accordance with this invention.

In Fig 5, optional step 501 shows the loading of the threshold configuration details 401 for a given tenant container 103 and corresponding application 104 by the monitoring facility 301. In some embodiments, this step 501 may be omitted such as when the monitoring facility 301 has fixed or predefined threshold configuration settings. Step 502 shows that for each "application activity" for which there is an "application activity indicator" configuration, a periodic check is made whether the relative or absolute quantity of some of, or all of, the "application activity indicators" have reached their respectively defined thresholds of idleness. If so, then the actions of the passivating facility are activated at Step 503. Otherwise, the periodic check is repeated one or more times in the future at step 502 again, until Step 503 is caused to be executed, or the tenant container and/or the corresponding application is terminated or shut down.

Fig 6 shows the passivating steps of a passivating facility indicated in step 503 of Fig 5. In Fi 6, a passivating facility is activated by the monitoring facility 301 upon a condition of idleness/inacti vity being reached for a given tenant 103 and

corresponding application 104 (as shown in Fig 5). The job of the passivating facility is to "passivate" the effected tenant 103 and corresponding application 104 in order t reduce its computational capacity and/or reservation (such as reducing its CPU reservation, and/or its memory reservation, and/or its IO reservation, etc) so that some or all of the computational capacity previousl reserved for the "passivated" tenant container 103 and corresponding application 104 can be made available for other non- passivated tenant containers and their applications.

In Fig 6 the step of one such passivating facility are shown- Step .600 commences the passivating activity. In Step 601 the thread(s), process(s), or task(s) of the tenant container 103 and corresponding application 1.04 that is to be passivated are suspended by the multi-tenant framework 102 (such as by an operating system kernel). An example of suspendin a process or suspending a thread in the Linux operating system is the "kill -SIGSTOP <PID>" command. Such a command in. the Linu operating system may he desirable to use in embodiments of this invention for Step 601. when the Linux operating syste is used as part of the multi-tenant framework 102.

In Step 602, an optional garbage collection action on the heap memory of the tenant container 103 and corresponding application 104 is performed in order- to tree memory capacity consumed by unreachable (dead) objects in the tenant container 103 and application 104. In other arrangements of steps 602, 603, 604A and 604B, some or all of the memory of the container 103 and application 1 4 to be passivated may be swapped out of RAM to disk.

In Step 603, the reserved heap quota of the container 103 and ap lication 104 to be passivated (suc as for example as was specified by the "-Xrox" command line parameter used to start a Java application 204), is reduced to be approximately the size of the post-garbage collection memory footprint such as after a garbage collection action has been performed in accordance with step 602.

In Steps 604A and 604B, the memory capacity difference between the .reserved heap quota and the post-garbage collection memory footprint (i.e. the "freed memory capacity") is made available to other nori-passivated tenant-confainer and their corresponding applications in optionally one of two arrangements.

In step 604A, some or all of the "freed memor capacity" is added to a shared pool of available memory capacity for use by some or ail of the no -passivated tenant- containers and their applications on a non-dedicated basis. Alternatively in step 604B, some or all of the "freed memory capacity" is added to the dedicated reserved heap quota for one or more non-passivated tenant-containers.

Finally in step 605, control or management or monitoring of some or all of the open file descriptors, open sockets, open server sockets, and the like of the tenant container and corresponding application being passivated, is commenced by an awakening facility. This is done without closing any of these files/descriptors/socfcets/server sockets.

Many different arrangements of a passivating facility will be apparent to those skilled in the computing arts that will be usable with this invention. Different arrangement of passivating facilities may change the order of steps described above and in Fig 6, as well as perform additional steps for new r different computational resource type not described herein (such as I/O or bandwidth capacity reservations). All such

alternative arrangements are to be understood to be included within the scope of the present invention. In Fig 7 an embodiment of the awakening steps of an awakening facility is shown which either periodically, or interactively through some event notification or callback means, observes some or all of the open Illes/descriptors/sGckets/server sockets/etc for signs of activity, while attempting to keep these files/descriptors/sockets/server sockets open and available. Upon identifying a sign of activity of or on any of the ope ffles/desicriptors/socfcets/server sockets which are being monitored or managed of controlled, the awakening facility then undertakes to activate the tenant 103 and application 104 to which the files/desciiptors/soekets/server sockets belong by carrying out one, some, or all of the steps of Fig 7.

Step 700 commence the passivating activity. In Step 701, a garbage collection action on the heap memory of one or more of the other (non-pas sivated) tenant containers and their corresponding applications is optionally performed.

In Steps 702, 703 A, and 703B, file reserved heap quota of the awakening tenant container 103 and corresponding application 104 i increased by partially or wholly reversing the effects of steps 603, 604 A and 604B undertaken for this tenant

previously, Various arrangements of Step 702, 703 A and 703 B can be used with the ultimate effect of increasing the memor capacity or memory reservation for the awakening tenant-container. Fig 7 shows two such arrangements as Steps 7Q3A and 703B. In other arrangement of Steps 701, 702, 703A, and 703B where the memory of the application to be awakened was earlier swapped out of RAM to disk, the swapped out memory is partially or wholly swapped back in to RAM again. Thus Steps 701, 702, 703A. and 703 B are the functional reverse of the actions undertaken in Steps 603. 604A, and 604B.

In Step 704, the m.read(s) or process(es) or task(s) of the awakening tenant container 103 and applicatio 104 are resumed on the .multi-tenant .framework 102. Thus step 704 is the functional reverse of the action(s) undertaken in step 601,

Finally in Step 705, control or management or monitoring of the open file descriptors, open sockets, open server sockets, and the like are ceased by the awakening facility, and control and management of all such files/descriptors/sockets/etc are resumed by the tenant container 103 and application 104 so that the tenant application can read and write from them thereafter in the same manner as prior to the undertaking of the passivation steps of Fig 6.

In further embodiments, and in a similar manner to the monitoring facility 301 of Fig 3, the awakening facilit ca optionally be configured wit arbitrary or user-supplied configurations, settings, details or properties which specify one, some, or all, of the following:

1.) the exact or approximate combination of files/descriptors/sockets/server

sockets to be monitored by the awakening facility

2) the exact or approximate actions which constitute activity for the a kening facility to respond to

3) the exact or approximate combination of filesVdeacriptors/sockets/seryer

sockets to not ^' be monitored by the awakening facility

4) the exact or approximate actions which do not constitute activity for the

awakening facility to respond to.

In yet another embodiment of this invention, the actions which constitute activity for the awakening facility to respond to include one, some or all of:

1 ) receiving transmitted data of a TCP or UDP socket

2) detecting the last-access timestamp of a file on a. file system changing

3) receiving an operating system signal.

In another embodiment of this invention, the actions which do not constitute activit for the awakening facility to respond to include one, or ail of:

1) TCP and/or UDP keep-alive packets being transmitted or received periodically

2) Internet control message protocol (iCMP) packets been transmitted or received periodically.

JSieep

In the following example embodiment of the present invention, the terms "Java

Virtual Container", "JVC", and "Java Container" are synonymous with a single

"tenant-container" ^' .or a single "tenant-application". In this example embodiment, the above-mentioned description is applied and implemented to allow the user t configure a JVC on the Waratek VM to

automatically transition from the Running state to the Paused state and vice- versa, provided certain predetermined conditions are satisfied. This is conveniently termed JSleep,

The following are examples of pause or suspend conditions:

• A prolonged situation of CPU idle state for the threads of the JVC.

• The lack of outgoing/incoming bytes from/to the sockets of the JVC.

• Reaching a predefined threshold (e.g. CPU usage, uptime, bytes sent/received, etc).

The following are example of resume conditions:

• Jf data is received by one of the sockets of the JVC.

• If a predefined timeout is reached (e.g. time of the day, interval of time

between wake-up calls, etc).

• If another JVC transitions to a different state (e.g. wak up JVC 1 if JVC 2 goes asleep, wake up JVC 1 if JVC 2 wakes up, wake up JVC 1 if JVC 2 shuts down, etc),

JSleep Thread

As schematically illustrated in Figs. S and 9, a predetermined single thready conveniently termed a JSleep thread, is responsible for checking suspend/resume conditions of each JVC at certain time intervals and, if necessary, taking the appropriate actions.

JSleep Actions

Each JVC is configured to have a JSieepProfiie. The JSleepProfiie is an abstract class. There are specific concrete subclasses of this class that are used to configure the JVC ^' s JSleep behaviour.

This is an extensible framework and allows users to adopt their own concrete implementations of the JSleepProfiie class. All that is required is that such classes are in the JVM' s elasspath. When a JVC transitions to the Paused state the following steps are taken;

• The JVC's dead objects memory is reclaimed by garbage collection (GC). « If the JSleepProfile was configured with MemoryType. VARIABLE, the

JVC's unused memory is re-assigned to the VM to be used for other JVCs. If, however, it was .configured with MemoryType. FIXED, no actions regarding memory will be taken,

* The JVC's threads are suspended.

♦ Open file descriptors (FDs) are kept open { ockets, files, etc).

When a JVC transition from the Paused state t the Running state the following steps are taken;

» If the JSleepProfile was configured with MemoryType, VARIABLE, the JVM will, make its best effort to rea sign the entire initial memory to the JVC. If it was configured with MemoryType.FiXED, no. actions regarding memor are taken.

• All the threads are resumed.

JSleep setup

JSleep can optionally be configured through the separate

cloudvm,management.VirtualContainerMXBean application program interface (API ) class of the CloudVM Management API, which is hereby incorporated for all purpose by cross reference.

Appendices 1-7 show the API documentation for an implementation of a JSleep facility for J VCs within the Waratek Java Virtual Machine.

If any other configuration method is requested (e.g. read from property file, or read from snapshot.xml file in the Waratek J VM), it is reconfigured to also go through this interface. The following code snippet shows how this is achieved:

// Get the VirrualMachineMXBean

VirtiiaiMachineMXBean vmbean = Management.Factor .getVirt ^" tmlMachmeMXBe n();

// Create VC

JavaContainerMXBean serverVc - vrobean.getJavaContainer(

v bean.createContainer{ "Container 1 \ "Java

DatagramSocketServer", null ) );

// Setup JSleepProfile

serverVc . sefJ SleepProfile( "cloudvni.jsleep .profile .NetworkProfile 120000 " ,

"FIXED" );

The code above creates a J VC called Container 1 running the DatagramSocketServer application and sets up its JSleep profile to be cloudYm.jsleep.profiie.NetworkProfile, with a timeout of 120 seconds. The MemoryType used is FIXED.

The VirtualContainerMXBean.setJSIeepProfile method takes two String arguments:

1. The config string, which starts with the fully qualified class name (FQCN) of the concrete JSleepProfile implementation to be used. After the FQCN, there is a space separated list of arguments. The need for arguments, their types and valid values are all defined by the concrete JSleepProfile implementation of choice.

2. The MemoryType string which defines the behaviour of the JVC's memory upon JSleep actions. There are two different categories of MemoryType, namely:

o VARIABLE:: upon suspension, the free memory of the JVC will be reclaimed by the J M, Upon resumption, the JVM will us a best effort approac to reassign to the JVC the memory with which it was pre vioLi si y configured

o FIXED: upon suspension no actions are taken regarding the memory of the JVC. Thus upon resumption the JVC is guaranteed to be assigned the memory with which it was previously configured.

User Implemented JSleepProfile

The JSleep framework gives the users the option to implement their own JSleep profiles if they wish. A custom JSleepProfile is required to extend the abstract class JSleepProfile and provide concrete .implementation, for its abstract methods, it also needs to be in the JVM ⁵ 5 classpath.

The foregoing describes only some embodiments of the present invention and modifications, obvious to those skilled in the computing arts, can be made thereto without- departing from the scope of the present invention.

The term "comprising" (and its grammatical variations) as used herein is used in the inclusive sense of "including ⁵ ' or "having" and not in the exclusive sense of "consisting onl of.

APPENDIX

Glass I 30uf.E e¾it

^bJ.J. c.1.¾S:S ¾· oat. £ V»»t

Constructor Summ y

Met od Summary

¾i i:?¾r d T e ft thod a«d 0¾&«.d toi

et od Detail

Class %t¾sl ci¾iy©di¾eii

Constructor $m elted Symmary

Constructor Detail

a ^-v 'x i;¾¾J ¾ ;¾;¾:?¾ ^■ Hs¾>

;ix:^rg¾«¾ .:;:¾;is;

Cl ss JSi®«pProfi!e

sat ds .:■:·"-·« . :. ¾f _; .C-- j*-.; v.

T _. iS S¾SiR¾¾! Ci3¾S _' ^' 3Si¾"lS¾ t;¾5 ::>jr'ti¾ ii! tev'SOr i&¾ ¾S0 ^' feji JSi<:¾p tSiStSS ^' S: T S SinS!¾te ¾;&: _< !3$¾§S ^; :'¾Ss¾¾i ί:ίΐ ίϊί.'! ^' ¾':ΐ

Sag y rfc »a:li&a¾¾i.»e i¾K ¾·> sss . ¾!i dd i&i s% y d as , s¾r ¾« ; ts>. i a ague ¾ JSissp roRteor «

Constructor Summary

. 'c ...

Me od Summary ¾® <i ¾ : ;!:y:o; ^' i?:&.^¾:; )? ^: r::;?:H:-

Construcor Detail

i¾tr! Detail

j¾(¾lii3 s r&ci *o ;J setu ' j^a. i.a;: con;: ig)

I ^k¾ss ¾¾&mi& ¾ ¾ £«si¾f¾¾¾i feds M i i

! c ck R sume

i:x^ JVC s ifcSd &i:rast-:j4 ; _: i¾i**;,s5S«f> s& _;

¾¾¾¾¾

: ^' :: S¾V¾W |ό;¾ί¾·Ί ¾;¾: ;¾»ίΐκ: ¾ iixfe His ^' s ^:¾a ϊ ΐ Η :¾ΐ ^;* ^' ^-

Class Net rki leEvem

is? ·:¾ Siass; sfssfite i? 3 ϊ ?<«;:¾:: hsss s¾itet5 si ksifi t - m f ¾i a

Con siructo r Sum m ry

¾%tted Summ ry

Met od s i n en red from cl ss J vaJ<¾ng. Object

¾SiSi ₅ ss¾¾a¾» _f ¾) _. s.t½aa, SiOlesv, «:>';¾·?:.>:¾>,. _? ¾ _¾ fci¾A¾ «iy.- ^> _u , _< v.,.

Constxuc r Detail

iSiriliiSii ^''

Class CpuEwt

Constructor Summary

Method Summary

Meh ds Inherited from class j&v^l&ng _* 0t^®Dt

Constructor Deal

ubli ; b vit x. ;.r: S

^¾V*S ^: [¾:Π ^: :■ :· ·' ϊ^ίίΐίίίΐ H¾K

S:i ¾:'.C- ) ¾ί i&fxj Sskij: ?¾« i ¾ί?«

T is« ^; -mss *fe»s fe« ® t ^ A ^j ^ s w jstess if m- nM&^^ ^

TE i ¾: ns¾ ··.* ^ ^m VARIABLE m ^ ^ risk ¾t m¾!-^^ ^^mmit it

¾um 0 ^; ar?saitt Summary

^• fris :;¾&!¾ ry o? trs® jvc¾¾s e¾J¾ is ysssj ss? ss |¾¾s.

S$@tFt©S Summary- odifie msi Ty$m ·„: ··:$·> :. i ?>ir . ·ν ^" ¾ΐ.««ΰ*".

M h ds inherited from ci es Java Jang. Ob ct

E SHUTS Cons t ¾t&i!

.::;u;:.^r>.r;->.l-.:y.y ;

¾¾v Disss feiiSsss s»;-:i:¾ S<& ?½;·Κ¾

ssrs N&K¾3a4s fSss:ss ¾¾ ¾:¾»s