Initial change for JDK8u152

Lock on JvmtiRedefine method

fixes dcevm8 lambda method unevolving

Fix problem with java8 breakpoints

Jvmti GetLoadedClasses collects classes from classloaders
in java8 while java7 collects it from SystemDictionary. Dcevm7/8
holds only new classes in Dictionary while classloader holds
all versions including old one. Therefore dcevm8 must return
only new version in jvmti getLoadedClasses.

README updates

Code generated by reflection must be deoptimized.

Update -XX:HotswapDeoptClassPath= for jdk8

Flag is used to specify set of packages to be deoptimized after class redefinition.
By default all classes are redefined that leads to performance drop.

Do not require jre directory to be prefixed with 'jre'

Installation instructions for Debian/Ubuntu

Patches: Jdk7u111 light/full, Jdk8u102, jdk8u111, jdk8u112

Patch for jdk7u85 is applicable on jdk7u111 as well. Dcevm for
jdk7u85 is binary compatible up to jdk7u99. The binary compatibility
for newer java7 versions is broken therefore dcevm for jdk7u111 is
necessarry. Same for jdk8u102 and higher.

Patch for jdk7u85 is applicable on jdk7u111 as well. Dcevm for jdk7u85
is binary compatible up to jdk7u99. The binary compatibility for newer
java7 versions is broken therefore dcevm for jdk7u111 is necessarry.

Patch for jdk7u85 is applicable on jdk7u111 as well. Dcevm for jdk7u85
is binary compatible up to jdk7u99. The binary compatibility for newer
java7 versions is broken therefore dcevm for jdk7u111 is necessarry.

Seems like f1 is still sometimes uses (in field scenario?) even though we zero bytecode, so it should be re-resolved.

fixes #94

Retrieved from http://hg.openjdk.java.net/mlvm/mlvm/hotspot

Light jdk7u85b02 support

should be compatible with 7u91 too

Duplicity distro patch removed from full patch.

Full jdk7u85b02 support

should be compatible with 7u91 too

closes #81