Wednesday Jun 25, 2014
Monday Jun 23, 2014
By Darryl Gove-Oracle on Jun 23, 2014
Once again I'll be presenting at Oracle Open World, and JavaOne. You can search the full catalogue on the web. The details of my two talks are:
Oracle Solaris Studio is an indispensable toolset for optimizing key Oracle software running on Oracle hardware. This presentation steps through a series of case studies from real Oracle applications, illustrating how the various Oracle Solaris Studio development tools have proven instrumental in ensuring that Oracle software is fully tuned and optimized for Oracle hardware. Learn the secrets of how Oracle uses these powerful compilers and performance, memory, and thread analysis tools to write optimal, well-tested enterprise code for Oracle hardware, and hear about best practices you can use to optimize your existing applications for the latest Oracle systems.
Many developers consider the deployment platform to be a black box that the JVM abstracts away. In reality, this is not the case. The characteristics of the hardware do have a measurable impact on the performance of any Java application. In this session, two Java Rock Star presenters explore how hardware features influence the performance of your application. You will not only learn how to measure this impact but also find out how to improve the performance of your applications by writing hardware-friendly code.
Friday Jun 20, 2014
By Darryl Gove-Oracle on Jun 20, 2014
Been isolating a behaviour difference, used a couple of techniques to get traces of process activity. First off tracing bash scripts by explicitly starting them with
bash -x. For example here's some tracing of
$ bash -x xzless + xz='xz --format=auto' + version='xzless (XZ Utils) 5.0.1' + usage='Usage: xzless [OPTION]... [FILE]... ...
Another favourite tool is
truss, which does all kinds of amazing tracing. In this instance all I needed to do was to see what other commands were started using
-f to follow forked processes and
-t execve to show calls to
$ truss -f -t execve jcontrol 29211: execve("/usr/bin/bash", 0xFFBFFAB4, 0xFFBFFAC0) argc = 2 ...
Friday Jun 13, 2014
By Darryl Gove-Oracle on Jun 13, 2014
For 32-bit apps the "default" maximum file size is 2GB. This is because the interfaces use the long datatype which is a signed int for 32-bit apps, and a signed long long for 64-bit apps. For many apps this is insufficient. Solaris already has huge numbers of large file aware commands, these are listed under man largefile.
For a developer wanting to support larger files, the obvious solution is to port to 64-bit, however there is also a way to remain with 32-bit apps. This is to compile with large file support.
Large file support provides a new set of interfaces that take 64-bit integers, enabling support of files greater than 2GB in size. In a number of cases these interfaces replace the existing ones, so you don't need to change the source. However, there are some interfaces where the long type is part of the ABI; in these cases there is a new interface to use.
The way to find out what flags to use is through the command
getconf LFS_CFLAGS. The
getconf command returns environment settings, and in this case we're asking it to provide the C flags needed to compile with large file support. It's useful to take a look at the other information that getconf can provide.
The documentation for compiling with large file support talks about both the flags that are needed, and what functions need to be changed. There are two functions that do not map directly onto large file equivalents because they have a long data type in their prototypes. These two functions are fseek and ftell; calls to these two functions need to be replaced by calls to
Wednesday Jun 11, 2014
Wednesday Jun 04, 2014
- New blog location
- Where does misaligned data come from?
- Misaligned loads profiled (again)
- Misaligned loads in 64-bit apps
- C++ rules enforced in Studio 12.4
- SPARC processor documentation
- Using the Solaris Studio IDE for remote development
- Community redesign...
- New Studio C++ blogger
- Building xerces 2.8.0
The Developer's Edge
Solaris Application Programming
- Coding for multiple threads on a CMT system
- Compiling for the UltraSPARC IIICu ...
- Cool Tools for SPARC systems overview
- GCC for SPARC Systems compiler options
- Improving Code Layout ...
- Interpreting UltraSPARC T1/T2 performance counters
- Memory ordering - part 1
- Memory ordering - part 2
- Performance Analysis Using SPOT
- Selecting Training Workloads ...
- Selecting the Best Compiler Options
- Sun Memory Error Discovery Tool
- UltraSPARC-IIICu Performance Counters ...
- Using Inline Templates ...
- Using Profile Feedback
- Using SHADE to Trace Program Execution
- Using VIS Instructions ...
- Using redistributable libraries
- CPU2006 training workload quality
- CPU2006 working set size
- Coding for multiple threads on a CMT system
- Compilers, Tools, and Performance - OpenSolaris Japan
- Developing and deploying software on the UltraSPARC-T1
- Evaluating training data for profile feedback ...
- Multithreaded programming for CMT sytems
- Parallelising a serial application
- SVOSUG Compiler Flags
- SVOSUG OpenSPARC
- SVOSUG Parallelisation
- SVOSUG book presentation
- Solaris and Sun Studio
- Strategies for improving the performance of serial codes on a CMT system
- Techniques for utilizing CMT