The -Xprof profiler is the HotSpot profiler. HotSpot works by running Java code in interpreted mode, while running a profiler in parallel. The HotSpot profiler looks for “hot spots” in the code, i.e. methods that the JVM spends a significant amount of time running, and then compiles those methods into native generated code.

The embedded HotSpot profiler is a specialist low overhead profiler suitable for running alongside the application while not causing too much of an overhead. It does this by being a very very simple profiler, using the lowest overhead techniques available. Firstly it samples the runtime stack (the methods currently being run) at regular intervals. In order to make this sampling have minimal impact, the interval between samples being taken is not too short. But much more importantly, unlike most stack sampling profilers, the stack is not “walked”, i.e. the elements on the stack are not identified in full. Instead only the topmost element of the runtime stack is identified, i.e. the method in which code is being executed at the sample time.

This sampling of the topmost runtime stack element is sufficient to identify which methods need to be compiled into native code. Basically, if any method is found to be at the top of the stack more than a few times, then the application can probably benefit from having that method compiled. Simple, but powerful.

So if the HotSpot profiler is always running, what does -Xprof do? It tells the profiler to keep a record of the profile information, and output that information at termination. The output is sent to stdout. Since most of the information needs to be kept by the profiler in any case, this means that -Xprof can actually be run in production without an excessive overhead being put on the application.

It is worth noting the severe limitations of this profiler. The information can be of very limited use. Because of its “minimal overhead” remit, there is minimal information available from the profiler:

Each thread has it’s profile recorded separately, and is output separately on thread termination; there is no combined view of the application runtime.

Only the top runtime stack method at sample time is identified, so there is no contextual information; being told that java.lang.String.equals is a bottleneck in your application is almost useless since you don’t know which of the many methods which call String.equals() is causing most of the trouble. (Note that it is fine for HotSpot, HotSpot doesn’t care about context, it just cares that String.equals() is a bottleneck, so that it knows it should spend some time compiling that method to native code.)

Only method execution is profiled; there is no object creation, garbage collection, or thread conflict profiling.

So is -Xprof useful? Yes, after all you are getting some profiling information for almost nothing. But it isn’t a sufficient profiler to performance tune on it’s own, except for very simple applications. And, of course, you only get output from -Xprof when the JVM includes HotSpot, which is not the case for all JVMs.

Reprinted from http://www.javaperformancetuning.com/

• Preface
• Compatibility
• Component Compatible Dependency
  • Interface-oriented programming
  • Single component signature protection
  • Single component compatibility protection
  • Multi-component compatibility compile time checking
• Summary

Preface

This article mainly includes three parts.at first,I will introduce compatibility principle(more details see here) briefly.followed by a detailed elaborating about Java component compatible dependency,including the interface-oriented programming,single component signature protection,single component compatibility protection and multi-component compatibility compile time checking.Finally is the review and prospect,especially about Dependency Mediator project.

Compatibility

what is compatibility？it is also the key to understanding the compatible dependency.Compatibility, often catch our eyes through two forms,binary compatibility,that means they can run the same executable code, typically machine code for a general purpose computer CPU.within the framework of Release-to-Release Binary Compatibility in SOM (Forman, Conner, Danforth, and Raper, Proceedings of OOPSLA ‘95), Java programming language binaries are binary compatible under all relevant transformations that the authors identify (with some caveats with respect to the addition of instance variables). here is a list of some important binary compatible changes that the Java programming language supports:

• Reimplementing existing methods, constructors, and initializers to improve performance.
• Changing methods or constructors to return values on inputs for which they previously either threw exceptions that normally should not occur or failed by going into an infinite loop or causing a deadlock.
• Adding new fields, methods, or constructors to an existing class or interface.
• Deleting private fields, methods, or constructors of a class.
• When an entire package is updated, deleting default (package-only) access fields, methods, or constructors of classes and interfaces in the package.
• Reordering the fields, methods, or constructors in an existing type declaration.
• Moving a method upward in the class hierarchy.
• Reordering the list of direct superinterfaces of a class or interface.
• Inserting new class or interface types in the type hierarchy.

eenerally,java language is upwards binary-compatible with previous version,such as Java SE 6 is upwards binary-compatible with J2SE 5.0 except for some minor incompatibilities.You can get details from here.

Another compatibility form,we call it source compatibility,meaning that recompilation is necessary.Java language does not support downward source compatibility. Such as if source files use new language features or Java SE platform APIs, they will not be usable with an earlier version of the Java platform. Usually it will throw similar error like this:

java.lang.UnsupportedClassVersionError: com.alibaba.mq.core.MessageConsumer :
     Unsupported major.minor version 51.0
     at java.lang.ClassLoader.defineClass1(Native Method)
     at java.lang.ClassLoader.defineClassCond(Unknown Source)

Java language source compatibility policy is as follows,except for any incompatibilities listed further below:

• Maintenance releases (such as 1.7.25, 1.7.26) do not introduce any new language features or APIs. They will maintain source-compatibility with each other.
• Functionality releases and major releases (such as 1.4.0,5.0,6.0,7.0,8.0) maintain upwards but not downwards source-compatibility.

Read More

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in trobuleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1

$ hexo new "My New Post"

More info: Writing

Run server

1

$ hexo server

More info: Server

Generate static files

1

$ hexo generate

More info: Generating

Deploy to remote sites

1

$ hexo deploy

More info: Deployment