JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 198 contents

https://www.youtube.com/watch?v=_bVcHCt-J6Y
A Post Apocalyptic sun misc Unsafe World (Page last updated April 2017, Added 2017-05-31, Author Christoph Engelbert, Publisher Devoxx). Tips:

• Reasons for using sun.misc.Unsafe include: avoiding object copies; volatile with array elements; custom memory allocation; fast memory access; custom memory fences; efficient memory layout; fast marshalling.
• sun.misc.Unsafe let's you create an object without running the constructors, this allows more efficient deserialization (avoiding setting the fields more than once).
• sun.misc.Unsafe provides compare-and-swap capability, but so does AtomicLong more safely, and if you want to apply to multiple fields you can use AtomicLongFieldUpdater, and from Java 9 VarHandle gives you the capability more generically.
• sun.misc.Unsafe let's you allocate offheap memory, ByteBuffer.allocateDirect() does so more safely, but is limited to 2GB memory allocation. VarHandles give you a "view" of memory that looks like other types of memory than bytes, eg view = MethodHandles.byteBufferViewVarHandle(long[].class, true); buf = ByteBuffer.allocateDirect(8); view.set(buf, 0, 100L); gives you an off heap memory which can be operated on using longs.
• sun.misc.Unsafe let's you allocate offheap memory without 32-bit limitations, NativeScope in Java 10 will let you do that, eg new NativeScope().allocate(NativeLibrary.createLayout(long[].class),10) gives you an off heap pointer to an array of 10 longs which can be operated on using longs.
• sun.misc.Unsafe let's you create an object without running the constructors, in Java 10 it's expected that you can use ReflectionFactory to do this yourself, eg ReflectionFactory.getReflectionFactory().newConstructorForSerialization(X.class,Xfield.class).newInstance(xxfield)

https://www.youtube.com/watch?v=gkWSrdSEL4o
The Invocation Game (Page last updated April 2017, Added 2017-05-31, Author John Rose, Paul Sandoz, Publisher Devoxx). Tips:

• MethodHandle is a dynamically typed reference to a method. It's like java.lang.reflect.Method, but much more powerful.
• MethodHandle.invoke() is similar in signature to Method.invoke(), but is much more efficient (it has fewer operations on the stack, and access control happens on lookup rather than execution). MethodHandle.invokeExact() is yet more efficient.

https://www.youtube.com/watch?v=CIjdipU66qw
Massive Parallelism with GPUs in Java (Page last updated April 2017, Added 2017-05-31, Author Adam Roberts, Publisher Devoxx). Tips:

• A typical machine will struggle to run many tens of thousands of JVM threads, but GPUs could help.
• GPUs are suitable where the problem can be massively parallelized, and there is a lot of data that needs processing. Machine learning is an excellent example. GPUs excel at running multiples of the same operation at once.
• GPUs are suitable where there are many primitive data types that need arithmetic operations, but there is not much branching or complexity, and the data can all be sent to the GPUs without operations needing to access more data. Not useful for code that needs network or file access, nor object creation and manipulation nor exceptions nor threads doing lots of different things.
• The IBM JVM has direct support for GPU usage with -Dcom.ibm.gpu.enable and -Xjit:enableGPU={default|verbose} with the JIT transparently using the GPU with no code changes.
• CUDA4J abstracts a lot of the boilerplate to use GPUs.

https://stackify.com/ultimate-guide-performance-testing-and-software-testing/
The Ultimate Guide to Performance Testing and Software Testing: Testing Types, Performance Testing Steps, Best Practices, and More (Page last updated May 2017, Added 2017-05-31, Author Angela Stringfellow, Publisher Stackify). Tips:

• Load testing measures the system performance as the workload increases under expected conditions to ensure that SLAs can be met. You should vary transaction count, concurrent users and data volume.
• Stress testing measures performance beyond expected conditions to see when the system breaks and how it handles under failure.
• Spike testing is a combination of load and stress testing where workload is mainly at expected conditions but goes beyond expected conditions for short amounts of time.
• Endurance testing is load testing for an extended period (typically needed to find slow resource leaks).
• Issues typically found in load testing include: speed issues (eg slow responses, long load times); bottlenecking (data flow interruptions); poor scalability (increased errors, long service time, other unexpected behaviour).
• Causes of performance issues include: Software configuration issues; Insufficient hardware resources; Software inadequacy.
• A performance testing process: record user scenarios; parametrize test scripts; group user scenarios; create load scenarios; simulate and execute load; analyze results; report.
• A performance testing process: specify the testing environment (hardware, software, network, tools); specify performance metrics (response time, throughput, success criteria); specify, create, configure & run the tests to be performed; analyze the tests, derive reports, make changes and retest as needed to achieve SLAs.
• Metrics to consider: Response time (average and longest); Error rate; Concurrent users; Requests per second; Throughput (bytes or transcations per second); CPU/Memory/IO utilization.
• Performance test in development. Performance test individual units and modules as well as the full system.
• Keep baseline measurements to compare for success or failure.
• Performance test in test environments that are as close to the production systems as possible.
• Use averages and outliers to decide on SLAs.
• Common performance testing fallacies that can easily bite you: performance testing is the last step in development; more hardware can fix performance issues; the testing environment is close enough; what works now works always and everywhere; one performance testing scenario is enough; testing each part equals testing the whole system; a full load test tells everything; test scripts are actual users.

Jack Shirazi

Back to newsletter 198 contents