przemelek [Sun, 19 Aug 2018 22:09:52 +0000 (15:09 -0700)]
Changes to display JVM installations on macOS/OSX.
Main change here is in Installer.java where scanDirectory was changed to work recursively, thanks to this we are able to find JVM on macOS which are in less predicable places ;-) on macOS JVM location will be for example /Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home, but scaning /Library/Java/JavaVirtualMachines/ without this recursive thing will not find JVM.
Additionally changed text in MainWindow which suggests now that users should prefer alternate JVM over replace JVM, with short "explanation" why.
Przemysław Rumik [Sat, 26 May 2018 11:21:54 +0000 (13:21 +0200)]
changes for support JDK8u172, needed to create dmh-field-accessors-java8u172.patch because in src/share/vm/classfile/vmSymbols.hpp getProtectionDomain have 2 new templates and old dmh-field-accessors-java8u80.patch wasn't able to merge
skybber [Sat, 3 Dec 2016 11:07:09 +0000 (12:07 +0100)]
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.
skybber [Fri, 28 Oct 2016 16:11:25 +0000 (18:11 +0200)]
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.
skybber [Sun, 23 Oct 2016 12:59:01 +0000 (14:59 +0200)]
Jdk8u102, jdk8u111, jdk8u112 patch
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.
skybber [Sun, 23 Oct 2016 09:07:50 +0000 (11:07 +0200)]
Jdk7u111 light + full patch
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.
skybber [Sun, 23 Oct 2016 09:07:50 +0000 (11:07 +0200)]
Jdk7u111 light + full patch
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.
Ivan Dubrov [Wed, 8 Jul 2015 19:57:59 +0000 (12:57 -0700)]
Cleaning up constant pool cache clearing code
Clear constant pool cache entries which are related to
invokehandle/invokedynamic and ones which are unresolved
(have both bytecodes set to 0).
There are two cases when such entries could be non-empty
(have data in f1/f2):
1. invokedynamic/invokehandle-related entries in which f2 was
set during constant pool cache initialization.
2. put/get into static field when class having the field
is not initialized yet.
Previously, we didn't clear such entries as clearing f2 in
first case results in crash. However, if we don't clear f1
in the second case, we will not be able to initialize class
for the second time (to re-create all enum constants, for
example) as non-empty f2 will cause assertion to fail.
The current implementation uses free bit in constant pool cache
entry to mark all entries with resolved indices (case #1).
The clearing code preserves f2 for all such entries.
projects / dcevm.git / log