2015 International Conference on Energy Systems and Applications (ICESA 2015)
Dr. D. Y. Patil Institute of Engineering and Technology, Pune, India 30 Oct - 01 Nov, 2015
Minimizing Impact on Java Virtual Machine via
JAVA Code Optimization
Vamsi Krishna Myalapalli, Sunitha Geloth
Open Text Corporation,
Mind Space IT Park, Hi-Tec City,
Hyderabad, India
{vamsikrishna.vasu, sunithasaini}@gmail.com
Abstract— In the contemporary programming microcosm
most of the commercial applications are contingent upon JAVA
programming language as front end language and is escalating
exponentially. Performance engineering the code plays a crucial
part. Many JAVA programmers code programs with less
contemplation towards optimized processing. Code tuning often
engenders massive performance enhancement. As such, the
proposed model is intended to bolster the JAVA programmers to
enhance and tune the JAVA code dependent application(s). This
paper exposes sundry miscellaneous rewriting techniques for
escalating JAVA application program performance towards
minimizing impact on JVM and could oblige as an optimization
tool for JAVA application programmer(s). Our investigatory
denouements advocate that performance enhancements i.e. Space
and Time complexities were enriched.
Keywords— JAVA Optimization; JAVA Tuning; JAVA Code
Rewrite; JAVA Performance Tuning; JAVA Code Tuning.
I. INTRODUCTION
Making programs run faster in a production environment is
a challenge for many developers. We can considerably
enhance the performance of the Server & applications
deployed on it by mutating some server configuration and
deployment settings.
Application developers should tune applications prior to
usage in production. Application Tuning results in massive
performance improvements. Once the application tuning is
complete System administrators carry out rest of the steps in
below list.
Sequence of Steps for performance tuning:
1. Application Tuning (The Proposed model).
2. Server Tuning.
3. Java Run time System Tuning.
4. Operating system Tuning.
Further paper is prepared as follows. Second section
explains the associated background and related work. Third
section deals with proposed benchmark i.e. the techniques.
Fourth section demonstrates experimental setup i.e.
implementing tactic. Section 5 explains comparative analysis
and finally section 6 concludes the paper.
II. BACKGROUND AND RELATED WORK
High Performance JAVA Programming [1] explained
sundry techniques to reduce time and space complexity in
commercial JAVA application code made of servlets, beans,
JDBC and other plain JAVA code. This paper encompasses
978-1-4673-6817-9/15/$31.00 ©2015 IEEE 19
techniques for reducing time and space complexity in plain
JAVA code and other best practices to minimize load levied
on the JVM.
High Performance C Programming [2] explained tuning
code via arithmetic logic, variable scope impact on the
compiler and other associated issues.
When tuning an application, the bottlenecks have to be
recognized. For example, if our code is processor bound the
algorithms should be tuned and short-lived objects must be
handled appropriately. Tuning bottlenecks is an incessant
process. Hence, critical ones must be handled accurately.
This paper explains the rewriting methodologies to reduce
object utilization in plain JAVA code and in turn, this tuned
plain JAVA code can be employed with other miscellaneous
code.
III. PROPOSED BENCHMARK
There exists sundry approaches for JAVA tuning and this
paper explains holistic techniques for JAVA tuning where we
optimize the JAVA application performance. We performed
snooping upon resource utilization using JProfiler profiling tool
and byte code using de-compiler software.
Code Handling #(1-8):
1) Concatenate Strings using String Builder: ‘String’ is
immutable whereas ‘StringBuilder’ is mutable. Performance
enhances if ‘StringBuilder.append()’ is used instead of string
concatenation. The latter case causes expensive copying &
upshots significant performance degradation.
2) Variables should be assigned null which are no Longer
Required: This tactic assists the garbage collector to recognize
the fragments of memory which can be securely reclaimed. It
should be noticed that it JAVA will not thwart memory leaks
and excess memory consumption.
3) Detecting Memory Leaks: Profiling tools help
programmers to detect memory leaks. Enforcing memory
snapshots after each transaction will also keep track of memory
leaks. Leak free applications ensure active heap memory after
subsequent garbage collection(s).
4) Moving to Final Methods on extreme necessity: The
‘final’ keyword thwarts over riding. Some Dynamic compilers
ensure ‘inter procedural optimization’ and ‘inlining’ if methods
are not final.
 5) Static Final Constants: Many of the Dynamic Compilers
ensure constant folding optimization when constants appear as
static final.
6) Strings as literals: Strings should be created as literals
instead of creating Strings using the 'new' keyword.
7) Prevent Finalizers: The Finalizer(s) are un-predictable
and might cause portability problems and severe performance
hitches . We should not put real time code in Finalizers under
any cost. Do not rest on on a finalizer in updating critical
persistent state.
8) Over riding the method toString(): This practice helps a
lot when the programmer is dealing with collections. As a best
practice toString should return vital information of the object.
Classes and Interfaces # (9-17):
9) Members and Classes Accessibility must be Curtailed:
This should be enforced as much as possible. Data members
must be kept hidden i.e. private and access to those must be
allowed via public methods. This ensures encapsulation or
information hiding. Classes holding public mutable fields will
not be thread-safe.
10) Implementing Functional Interface(s) via Lambda(s):
They let us define default behavior for an interface and refer to
the method without executing them. They eliminate verbosity.
11) Mutability must kept to minimum: Immutable objects
are thread safe and can be freely shared along with their
members. Inorder to ensure immutability make classes and
their members final.
Immutability ensures easy to use, test and failure atomic.
In addition, they do not need defensed copying or cloning. Ex:
Integer, String etc.
12) Inheritance vs. Composition: (Is-A) Inheritance
makes code fragile and violates encapsulation. Rather than
extending current class, offer the new class a private field
which references an instance of current class (Composition
(Has-A)).
13) Deter Abstract Classes over Interfaces: Interfaces
force the class to define its own definition which implements
it. Inheriting abstract classes may result in collateral harm to
type hierarchy. Interfaces permit creating non-hierarchical
type frameworks and are idyllic for developing mixins.
14) Prefer Simulated Multiple Inhheritance: The class
which implements interface could forward invocation(s) of
interface functions to contained instance of private inner class
which extends the skeleton implementation. SMI allows
inheriting multiple classes (easiest method for evolving an
abstract class instead of Interface).
After launching and implementing interface, it’s
practically difficult to modify the application code, hence
prefer SMI.
15) Utilize interface(s) solely for defining type(s):
Interface(s) must not be used for propagating constants. It’s a
poor utilization of Interface.
16) Choose Hierarchy of class over Tagged Classes:
Tagged classes are longwinded, ineffective and fault prone.
20
Memory footprint might be increased by Tagged Classes as
they are clutter the code with switches, tag field(s) and enums
etc. For transmuting a tagged class into class hierarchy, define
abstract class holding an abstract method for individual
method in tagged class whose functionality depends on tag
value.
17) Favor Static Member Classes over Nonstatic: The
relationship among a non-static member class instance & its
encompassing instance is generated after the former is created;
it can’t be altered afterwards. Since this association consumes
memory in non-static member class instance and takes time
for its creation Non static member classes should be deterred.
Generics #(18-23):
18) Deter Raw types in Code: Type safety is lost if we
encourage raw types in code. On the other hand the rate of
bugs will increase.
19) Obliterate Unchecked Warnings: Getting rid of
unchecked warnings (ClassCastException) makes the code
type safe.
20) Favor Lists over Arrays (Generic): Generics remain
invariant and Arrays remain covariant.
21) Prefer Generic methods: Type safety is secured with
generic methods similar to classes. Static utility methods serve
as best contenders to generify.
22) If API flexibility to be escalated, enforce Bounded
Wild Cards: This allows additional flexibility to what
invariant typing could offer.
23) Consider Typesafe Heterogeneous Containers: This
provides type safety for the parameters of the container.
Enums # (24-27):
24) Prefer Enums instead of Constants: Switch upon
enum is best to augment external enum type by constant
precise behavior.
25) Prefer Instance Members over Ordinals: ordinal
method gives numeric location in enum.
26) Use EnumMap instead of Ordinal Indexing: Since
array isn’t compatible with generics code requires an
unchecked casting. Also there exists probability for mistake in
calculating array indices with ordinal indexing. EnumMap
adds typesafety of Map to array speed.
27) Emulating Extendable Enum(s) from Interface(s): We
can’t compose extensible enum, but we could emulate it via
interface. Thus permitting end users to compose specific
enum(s) which implement that interface.
General #(28-33):
28) Enforce Marker Interface(s) for defining type(s):
Interfaces with no methods are Marker/Tagged Interfaces.
(Ex: Serializable). Marker interface(s) express a type which
will be implemented by instance(s) of Marked class, allowing
us to catch blunders during compile time.
29) Return Blank Collections or Arrays instead of
returning Nulls: This occasionally minimizes load on JVM.
 30) Favor for-each loop over while/for loop: For-Each
hides iterator or index variable and marks the code
uncluttered.
31) Favor Primitive type(s) over Boxed primitive(s):
Primitive (contains solely fully functional values) is usually
less space and time complexive compared to that of boxed
primitive (contains 1 non-functional value). If primitve and
boxed primitive is mixed or program boxes primitive(s), it
results in creating needless and expensive objects.
32) Prevent Strings if another type is suitable: String is
inappropriate alternative for enum, aggregate and primitive
type, since they are slower and not much flexible.
33) Reference Objects via their Interfaces: We must
favor the use of interfaces rather than classes to refer to
objects. If applicable interface type is present, then variable(s),
parameter(s), return value(s), and fields must be declared by
interface type(s). This ensures flexibility for code.
Exceptions # (34-37):
34) Checked vs Unchecked (Runtime) Exception: We
should enforce checked exception on condition to which
invoker could practically recovered. On the other hand enforce
unchecked exception (subclassing RuntimeException) for
indicating coding error.
35) Prevent Needless Checked Exception(s): More
checked exceptions will clutter the API. Runtime exceptions
will perform fine when normal code cannot perform well.
36) Raising Exception Applicable to Abstraction: Raised
exception should be relevant with code. If implementation at
high layer is changed, then with succeeding code, the
exception it throw would change, breaching current end user
code. Prevention: Implement ‘Exception Translation’ i.e. High
must catch low layer exception(s). ‘Exception Chaining’ could
strengthen this process.
37) Never Overlook Exceptions: Blank catch block beats
the neccessity for an exception. On minimum, it must
comprise comment enlightening the reason for its presence.
Threads #(38-47):
38) Ensure Thread Safety: If various threads share data,
every thread which writes or reads data should undergo
synchronization.
39) Evade Extreme Synchronization: Surplus sync drags
down performance and may trigger deadlock. In synchronized
body don’t invoke method which could be overridden or
offered from client in the form of method object (alien
method).
40) Favor Tasks and Executors over Thread(s): Executor
is a malleable interface dependent execution feature for tasks.
Scheduled thread-pool executor will allow several threads and
recover graciously from tasks which throw unchecked
exception(s).
41) Favor Concurrency Utilities over notify and wait:
Concurrency utilities of high level must be enforced, since
wait and notify will lock and decelerate code.
21
42) Notify vs notifyAll: Prefer notifyAll over notify to
ensue liveness for threads. This will not lead to abrupt issues.
43) Focus on Lazy Initializing: This minimizes burden of
initializing class or creating instance, on escalating price of
accessing lately initialized field. We can initialize lazily to
attain performance and to break risky initializing circularity.
44) Never rely over Thread Scheduler: Though this
escalates performance, it makes our code non-portable and
non robust. (Ex: yield and priority methods).
45) Favor Thread pool Executors over Thread Groups:
‘Thread groups’ sequester applets for security. They doesn’t
provide efficient functionality and performance.
46) Deal with Serializable meticulously: This minimizes
the elasticity in altering a class design after it is
distributed/released apart from increasing testing burden and
the certainity for bugs and security glitches.
47) Prefer Serialization Proxies over Serialized
Instances: Create static private inner class of serializable class
which briefly signifies logical state of object of encompassing
class. This inner class is serialization proxy ans minimizes
glitches faced with Serializable clause.
Miscellaneous # (48-51):
48) Deal with Native methods meticulously: They are
used for backward compatibility (C, C++) and for
performance. This makes the code non-portable.
49) Favor 2 element enum type over boolean type: This
offers the program R/W capability and allows auto-completion
IDE.
50) Implement Singleton Pattern wisely: Singleton makes
it tough to examine its clients, since it is not probable for
replace a mock design to singleton except if it is implementing
an interface which could serve as its type.
51) Enforce Defensed Copy over Mutable fileld(s):
Defense copying thwarts modification of mutable field(s).
IV. EXPERIMENTAL SETUP
In this section, some of the tactics specified in immediate
earlier section are explained via queries aiming that they serve
as an exemplary. We have tested these code snippets for
evaluating memory leaks, time and space complexity using
JProfiler profiling tool.
1. a) StringBuilder tmp = new StringBuilder("Hackers");
tmp.append("Galaxy");
tmp.append("Astronomy");
String str = tmp.toString();
Instead of
b) String strn = "Hackers";
strn = strn + "Galaxy";
strn = strn + "Astronomy";
The compiler translates the second case into following
String strn = "Hackers";
StringBuilder tmp = new StringBuilder(strn);
 tmp.append("Galaxy");
strn = tmp.toString(); 14. interface IPenguin { public void lay(); }
StringBulder tmp = new StringBuilder(strn); interface IKangaroo { public void spawn(); }
tmp.append("Astronomy"); class Penguin implements IPenguin {
strn = tmp.toString(); public void lay() { System.out.print("Laying"); }
}
2. Moon m = new Moon(); class Kangaroo implements IKangaroo {
// Code part that uses m public void spawn(){System.out.print("Spawning");}
m=null; // Now ‘m’ is qualified for Garbage collection }
System.gc(); class DuckBPlatypus implements IKangaroo, IPenguin {
Above statement is equivalent to private class LayingAnimal extends Penguin {}
Runtime.getRuntime().gc() private class SpawningAnimal extends Kangaroo {}
private LayingAnimal layingAnimal = new
6. String do = “Hard Work Never Fails”; LayingAnimal();
Instead of private SpawningAnimal spawningAnimal = new
String do = new String (“Hard Work Never Fails”); SpawningAnimal();
@Override
10. interface Roof public void lay() { layingAnimal.lay(); }
{ int makeInc(int g); } @Override
public class Home public void spawn() { spawningAnimal.spawn(); }
{ }
public static void main(String... z)
{ 15. class MyConstants
Roof r = (n) -> n+1; // Anonymous over ride {
System.out.print( r.makeInc(9) ); private MyConstants() { } // Prevents instantiation
} } static final double const1 = 76.76, const2 = 32.32;
Instead of }
interface Roof Instead of
{ int makeInc(int g); } interface MConstants
public class Home implements Roof { static final double const1 = 76.76;
{ static final double const2 = 32.32; }
public int makeInc(int g)
{ return g+1; } 16. class Polygon {
public static void main(String... z) enum Shape { SQUARE, OVAL };
{ final Shape shaped; // Tag field - Shape of this Polygon
System.out.print(new Home().makeInc(9)); double length, width; // fields used only for SQUARE
} } double rad; // fields used only for OVAL
Polygon(double rad)
12. class Profession { { shaped = Shape.OVAL; this.rad = rad; }
private int income; Polygon(double length, double width)
public int getIncome() { return income; } { shaped = Shape.SQUARE; this.length = length;
public void setIncome(int income) this.width = width;
{ this.income = income; } }
} double area() {
class Individual { switch(shaped) {
private Profession prof; case SQUARE: return length * width;
public Individual() case OVAL: return Math.PI * (rad * rad);
{ this.prof=new Profession(); prof.setIncome(1000); } default: throw new AssertionError();
public int getIncome() { return prof.getIncome(); } }
} }
public class CompoTest { }
public static void main(String... zz) {
Individual person = new Individual(); 17. class Out
System.out.print(person.getIncome()); {
} static class In
} { // Members }
// Individual Has-A Profession }

22
 Instead of f.putFav (String.class, "Java");
Class Out f.putFav (Integer.class, 0xcafebabe);
{ f.putFav (Class.class, Favorites.class);
Class In String favStrn = f.getFav (String.class);
{ //Members } int favInt = f.getFav (Integer.class);
} Class<?> favClass = f.getFav (Class.class);
System.out.print("%s %x %s%n", favStrn,
19. Set<Apps> app = new HashSet<Apps>(); favInt, favClass.getName ());
Instead of
Set<Lark> app = new HashSet(); // Gives warning 24. enum Moons
{
20. Case 1: // Fails on compile, due to incompatibility EARTH(1), MARS(2), JUPITER(67), SATURN(62);
List<Object> xl = new ArrayList<Double> (); private int mooncount;
xl.add("can’t come now "); private Moons (int mooncount)
Case 2: // Runtime Failure (Bug in Code) { this.mooncount = mooncount; }
Object[] xl = new Long[2]; public int getmooncount() { return mooncount; }
xl[0]= “can’t come now"; // ArrayStoreException }
public class MoonTest {
21. static <E> Set<E> unite (Set<E> q1, Set<E> q2) { Moons moon;
Set<E> res = new HashSet<E> (q1); public MoonTest(Moons moon) { this.moon = moon; }
res.addAll(q2); }
return result; Moons.MARS.getmooncount(); // Invoking this returns 2
} Instead of
Instead of public static final int EARTH=1, MARS=2, JUPITER=67;
static Set unite (Set q1, Set q2) {
Set res = new HashSet (q1); 25. enum Moons { private int mooncount;
res.addAll(q2); EARTH(1), MARS(2), JUPITER(67);
return res; private Moons (int mooncount)
} { this.mooncount = mooncount; }
public int getmooncount() { return mooncount; } }
22. void addAll(Iterable<? extends E> source) { Instead of
for (E z : source) enum Moons { private int mooncount;
push(z); // Insert value to some store EARTH(1), MARS(2), JUPITER(67);
} private Moons(int mooncount)
Instead of { this.mooncount = mooncount; }
void addAll(Iterable<E> source) { public int getmooncount() { return ordinal()+1; } }
for (E z : source)
push(z); 26. public class Crop {
} public enum Type {BIENNIAL,ANNUAL,PERENNIAL}
In case 1, the method can accept any kind of number i.e. private final Type typ; private final String labl;
Integer, double etc, without compromising at type safety. Crop(String labl, Type typ)
{ this.labl = labl; this.typ = typ; }
23. class Fav { }
private Map<Class<?>, Object> favs = Then
new HashMap <Class<?>, Object> (); Map<Crop.Type, Set<Crop>> cropsByType =
public <T> void putFav (Class<T> typ, T instnc) new EnumMap<Crop.Type, Set<Crop>>(Crop.Type.class);
{ for (Crop.Type z : Crop.Type.values())
if (typ == null) cropsByType.put (z, new HashSet<Crop>());
throw new NullPointerException ("Invalid"); for (Crop c : garden)
favs.put ( typ, instnc ); cropsByType.get(c.typ).add(c);
} System.out.println(cropsByType);
public <T> T getFav (Class<T> typ) { Instead of
return type.cast ( favs.get (typ) ); Set<Crop>[] cropsByType =
} ( Set<Crop> []) new Set[Crop.Type.values().length];
} for (int z = 0; z < cropsByType.length; z++)
// The upcoming code goes into main() cropsByType[z] = new HashSet<Crop>();
Fav f = new Fav(); for(Crop c :garden) cropsByType[c.typ.ordinal()].add(c);

23
 for (int z = 0; z < cropsByType.length; z++)
System.out.printf("%s : %s %n",
Crop.Type.values()[z], cropsByType[z]);
27. interface IMoons { public int getMoons(); }
enum Moon implements IMoons {
MARS { @Override public int getMoons() { return 2; }},
EARTH {@Override public int getMoons() { return 1; }},
JUPITER {@Override public int getMoons() {return 67;}};
public int getMoons() { return 1; } }
Then statement Moon.MARS.getMoons() Gives 2
33. List<Moon> moons = new ArrayList<Moon> ();
Instead of
ArrayList<Moon> moons = new ArrayList<Moon> ();
36. try { ... }
Catch(InferiorLevelException e)
{ throw new SuperiorLevelException(...); }
40. ExecutorService es =
Executors . newSingleThreadExecutor ();
//Now submit runnable to execute
es.execute ( runnable );
// Now Terminating gracefully
es .shutdown();
47. public final class Period {
private final Date begin, stop;
Period(Date begin, Date stop)
{ programming language in numerous commercial application
this .begin = new Date ( begin.getTime() );
this .stop = new Date ( stop.getTime() );
} concerned with upgrading existing hardware on the other hand
private static class SerializingProxy
implements Serializable
{
private final Date begin, stop;
SerializingProxy(Period p) {
this .begin = p .begin; this .stop = p .stop; }
private Object readResolve() {
return new Period ( begin , stop );
// Public constructor used
} [3]
49. public enum Boolean{
TRUE(true), FALSE(false);
private Boolean(boolean decision)
{ this.decision = decision; }
private final boolean decision;
public boolean booleanDecision() { return value; }
public String toString()
{ return value ? "true" ; "false"; } }
50. public enum SingletonPattern
{ INSTC; }
Instead of
24
public class SingletonPattern
{
public static final Elvis INSTC = new SingletonPattern ();
private SingletonPattern () { }
static SingletonPattern getInstc() { return INSTC; }
}
51. Date raiseDate; // Mutable field
public Date getraiseDate ()
{ return new Date(getraiseDate.getTime()); }
Instead of
public Date getraiseDate()
{ return raiseDate; }
Now, even if returned object is modified, the genuine
one is stays unaffected.
V. COMPARATIVE READING
We rewrote the code and recognized the resource utilization
using JProfiler profiling tool and noticed that tuning and long-
term maintenance are ensured. Apart from profiling the code,
we also investigated the byte code (.class files) using de-
compiler against source code. Comprehensively rate of bugs
were reduced and security is enhanced apart from decreasing
time and space complexities. Our analysis could serve as
benchmark practices for JAVA programmers in the form of
White box testing tool for questing concealed bugs.
VI. CLOSING COMMENTS
JAVA tuning plays a key role in the programming
microcosm, due to the reason that JAVA is used as front-end
developments. Tuning brings out huge performance
enhancement irrespective of the platform. Hardware tuning is
software-tuning concentrates on tuning programming
methodologies and practices.
REFERENCES
[1] Vamsi Krishna Myalapalli and Sunitha Geloth, “High Performance
JAVA Programming”, IEEE International Conference on Pervasive
Computing, Pune, India, January 2015.
[2] Vamsi Krishna Myalapalli, Jaya Krishna Myalapalli and Pradeep Raj
Savarapu, “High Performance C Programming”, IEEE International
Conference on Pervasive Computing, Pune, India, January 2015.
Joshua Bloch, “Effective JAVA”, Edition 2, Addisson Wesley
Publishers, 2002.
[4] Vamsi Krishna Myalapalli, Sunitha Geloth and Srinivas Karri, “An
Appraisal to Secure JAVA Programming”, International Journal of
Innovative Research in Science, Engineering and Technology, Volume
4, Issue 9, September 2015.
[5] Vamsi Krishna Myalapalli and Bhupati Lohit Ravi Teja, “High
Performance PL/SQL Programming”, IEEE International Conference on
Pervasive Computing, Pune, India, January 2015.
[6] Vamsi Krishna Myalapalli and Pradeep Raj Savarapu, “High
Performance SQL”, 11th IEEE International Conference on Emerging
Trends in Innovation and Technology, December 2014, Pune, India.
[7] Paul Deitel, Harvery Deitel “JAVA How to Program”, 8th Edition 2010.
PHI Publications, ISBN: 978-81-203-3832-6.