Re: JDK 9 RFR of 8032397: Remove sun.misc.Ref
On 22/01/2014 01:17, Joe Darcy wrote: Hi Alan, Updated webrev at http://cr.openjdk.java.net/~darcy/8032397.1/ @see in sun.misc.Ref removed. Regression tests updated to not refer to sun.misc.Ref. I looked at the use of Ref in jhat and it is only used if java.lang.ref.Reference is not found reflectively, so I think the existing code can stay in place. Looks good to me. A minor comment on AppletImageRef is that url can be final. (My comment on jhat was just wondering whether the lookup of sun.misc.Ref should be removed or not. It's harmless of course and seems to a relic of the past). -Alan.
hg: jdk8/tl/jdk: 8032217: failure in man page processing
Changeset: ff56039c4870 Author:erikj Date: 2014-01-22 12:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff56039c4870 8032217: failure in man page processing Reviewed-by: dholmes, tbell ! make/Images.gmk
Re: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format.
Kumar, see my notes inline. On 1/21/14 20:11, Kumar Srinivasan wrote: Alex, Thanks for adding the test, few comments: PackTestZip64.java: 1. compareTwoFile, I would read the entire file into ByteArrayInputStream, compare the total first ie. fast fail, but what you have is also ok. I've tried the approach of reading the entire file into memory and it doesn't seem to speed up the process so much, so i'd left it as it is. 2. generateLargeJar: I would replace lines 126,127 and 128 using for-each loop, by using Collections.listEnumeration e); will make it more compact. Done. 3. Though the test might not take too long on your system, I am concerned it may take too long on our Jprt system. I tested it on JPRT - there's no system on which test takes more than a minute - actually the longest test run time was on the solaris-sparc and it's 44 seconds, so it seems it's Ok. The updated webrev can be found at: http://cr.openjdk.java.net/~kizune/8029646/webrev.03 /Alex Kumar On 1/16/2014 8:21 AM, Alexander Zuev wrote: Sherman, Kumar, i have fixed the glitches you have found and changed the test so it creates a new jar based on the golden.jar content (to have a reasonable set of various data to start with), then adding to it 65536 empty files to test how we cope with such a huge jars. The testing time is less than a 30 seconds on my machine (not the top-of-the-line) so i decided not to bother with conditional testing, lets test our behavior every time in full. The updated webrev can be found at http://cr.openjdk.java.net/~kizune/8029646/webrev.02 /Alex On 1/15/14 21:34, Xueming Shen wrote: On 1/15/14 7:01 AM, Alexander Zuev wrote: Hello, the new webrev with all the typos and comments fixed can be found at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/ /Alex (1) jarmagic can be just a static constant somewhere or a stack variable. not big deal though. (2) the test only tests EOF for s. there is possibility that the newly created has more extra bytes at the end...though in theory this should not happen, it might be better just add an extra line to check the sizes of two first first? (3) the rest of the change looks good, but I agreed with Kumar that you may need to add a regression test for a jar file with 64k entries. otherwise the code for zip64 end is not being tested. the code looks fine, but I would trust a regression test more than my eyes:-) Thanks! -Sherman
Re: JEP 187: Serialization 2.0
On 01/14/2014 01:26 AM, mark.reinh...@oracle.com wrote: Posted: http://openjdk.java.net/jeps/187 There's another aspect of the current approach to serialization that is not mentioned: the type information does not come from the calling context, but exclusively from the input stream. This means that all serializable classes can be instantiated, and not just those the context is prepared to deal with. I don't know if this is worth changing, but I do think it's something to consider. -- Florian Weimer / Red Hat Product Security Team
Re: JEP 187: Serialization 2.0
On 22/01/14 13:57, Florian Weimer wrote: On 01/14/2014 01:26 AM, mark.reinh...@oracle.com wrote: Posted: http://openjdk.java.net/jeps/187 There's another aspect of the current approach to serialization that is not mentioned: the type information does not come from the calling context, but exclusively from the input stream. Have you overlooked resolveClass [1], or are you looking for additional context? -Chris. [1] http://download.java.net/jdk8/docs/api/java/io/ObjectInputStream.html#resolveClass-java.io.ObjectStreamClass- This means that all serializable classes can be instantiated, and not just those the context is prepared to deal with. I don't know if this is worth changing, but I do think it's something to consider.
Re: JEP 187: Serialization 2.0
On 01/22/2014 03:47 PM, Chris Hegarty wrote: On 22/01/14 13:57, Florian Weimer wrote: On 01/14/2014 01:26 AM, mark.reinh...@oracle.com wrote: Posted: http://openjdk.java.net/jeps/187 There's another aspect of the current approach to serialization that is not mentioned: the type information does not come from the calling context, but exclusively from the input stream. Have you overlooked resolveClass [1], or are you looking for additional context? I mean something slightly different, so here's a concrete example: Assume we are deserializing an instance of a class with a String field. The current framework deserializes whatever is in the input stream, and will bail out with a ClassCastException if the deserialized object turns out unusable. Contrast this with an alternative approach that uses the knowledge that the field String and will refuse to read anything else from the input stream. -- Florian Weimer / Red Hat Product Security Team
Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement
On Jan 21, 2014, at 11:05 PM, Xueming Shen xueming.s...@oracle.com wrote:
Hi Paul, thanks for reviewing the changeset, comment inlined below.
On 01/20/2014 09:24 AM, Paul Sandoz wrote:
Some quick comments.
In String.toLowerCase:
- it would be nice to get rid of the pseudo goto using the scan labelled
block.
webrev has been updated to remove the pseudo goto by checking the first
against
len after the loop break.
Much for readable :-)
- there is no need for the localeDependent local variable.
I just tried to not throw away the result of this localeDependent, which is
still needed
in the toXCaseEx() methods.
if (lang == tr || lang == az || lang == lt) {
// local dependent
return toLowerCaseEx(result, firstUpper, locale, true);
}
// otherwise false is passed to subsequent calls to toLowerCaseEx
?
- you might be able to optimize by doing (could depend on the answer to the
next point):
int c = (int)value[i];
int lc = Character.toLowerCase(c);
if (.) { result[i] = (char)lc; } else { return toLowerCaseEx(result, i,
locale, localeDependent); }
- Do you need to check ERROR for the result of toLowerCase?
2586 if (c == Character.ERROR ||
Yes, Character.toLowerCase() should never return ERROR (while the package
private
Character.toUpperCaseEx() will). In theory there is no need to check if the
return
value of Character.toUpperCase(int) min_supplementary_code_point in our
loop,
because there is no bmp character returns a supplementary code point as its
lower
case. But since it's a data driven mapping table, there is no guarantee the
unicode
data table is not going to change in the future, so I still keep the check.
The webrev
has been updated to use one single if inside the loop.
I have a single if implementation for the toUpperCase() as well, though
don't sure
which one is better/faster :-)
OK, i suppose one could measure :-)
Not sure how much it is worth obsessing over but...
int c = (int)value[i];
if (c '\u03A3') {
result[i] = (char)Character.toLowerCase(c); // Is that safe?
} else if (c Character.MIN_HIGH_SURROGATE c != 'u03A3' (c =
Character.toLowerCase(c)) Character.MIN_SUPPLEMENTARY_CODE_POINT)) {
result[i] = (char)c;
} else {
return toLowerCaseEx(result, i, locale, localeDependent);
}
or:
int c = (int)value[i];
int lc = Character.toLowerCase(c); // is that safe?
if (c '\u03A3') {
result[i] = (char)lc;
} else if (c Character.MIN_HIGH_SURROGATE c != 'u03A3' lc
Character.MIN_SUPPLEMENTARY_CODE_POINT)) {
result[i] = (char)lc;
} else {
return toLowerCaseEx(result, i, locale, localeDependent);
}
or:
int c = (int)value[i];
int lc = Character.toLowerCase(c); // is that safe?
if (c '\u03A3' || (c Character.MIN_HIGH_SURROGATE c != 'u03A3' lc
Character.MIN_SUPPLEMENTARY_CODE_POINT))) {
result[i] = (char)lc;
} else {
return toLowerCaseEx(result, i, locale, localeDependent);
}
FWIW i personally find those solutions easier to read, if they are safe w.r.t.
Character.toLowerCase and that annoying greek character.
Paul.
http://cr.openjdk.java.net/~sherman/8032012/
-Sherman
Re: JEP 187: Serialization 2.0 Serialization-aware constructors
On 01/13/2014 06:26 PM, mark.reinh...@oracle.com wrote: Posted: http://openjdk.java.net/jeps/187 The concept of explicit deserialization constructors is interesting and is something I've explored a little bit in the context of JBoss Marshalling. The way construction works today (simple version!), the framework will magic up a new Constructor instance which can construct a partially-initialized object. By partially initialized I mean, only the classes in the non-serializable top half of the class hierarchy are initialized, subclass-first like always. At this point it relies on the language constraints that require that the superclass be initialized as the first step (more or less) of construction, thus effectively reversing initialization order to be superclass-first. Now at this point there is an object that was (more or less) initialized from the top (Object) down to the last non-serializable class in the hierarchy (which is often also Object, as it happens). From here, the deserialization mechanism takes over, using stream information to acquire values and stuff them into fields (even final fields) using reflection, in superclass-first order. Some reflection magic makes sure that final field publication works more or less as expected; some other magic ensures that sensible action is taken for certain types of differences in the sending and receiving class structures. No initializers are ever invoked for these classes, though you can define a private readObject() method which is a close approximation (as long as you don't have final fields, else you're stuck using reflection too). The idea with a serialization-aware constructor is that each serializable class constructor can read the stream information itself and initialize fields the normal way, with normal validation. The simplest/most naive implementation of this is to simply pass in an ObjectInputStream to these constructors. This approach seems to work fairly well actually, from the user's perspective: each constructor calls to the superclass first, then it acquires (for example) a GetField object for itself and then pulls field data out of it and populates its real fields, much like a readObject() method might do. The problem here is that the actual serialization implementation normally gets to hook in between calls to readObject(); it cannot do this for constructors, because each constructor calls the superclass' immediately in a chain. The framework would have to examine the call stack to know who the actual caller is, and there is also the possibility that the constructors would abuse this contract in various ways, taking advantage of the framework's lack of control. In an ideal world (for serialization implementations anyway), constructors would be wholly isolated, which would allow the framework to call each one in sequence with only its safely isolated bit of the stream. But in the real world, this isn't really possible within the framework of the existing language. One concept that might be interesting would be to introduce such isolated instance initializers which do not call up to the superclass but which otherwise follow the general constructor contract. This would present a very simple solution from the perspective of serialization, though the complexity of such a solution is potentially great. Another option is to establish a tighter API which constructors can consume. The constructor would be able to read field information out of the API but only for its own class, possibly even enforced by call stack inspection. The constructor would be contractually obligated to propagate the API object to the superclass; the framework would have to enforce that the propagation happened correctly for the class hierarchy (which it would have knowledge of), i.e. ensure the object didn't cheat by calling a non-serialization constructor for a serializable superclass. Other ideas may be possible as well. I found this to be an interesting problem when I was exploring it myself, and I still find it pretty interesting. -- - DML
Re: RFR: 8030822: (tz) Support tzdata2013i
Looks good to me Aleksej. Hopefully you can get a reviewer from the i18n dev team also. regards, Sean. On 21/01/14 13:17, Aleksej Efimov wrote: Hi, Can I have a review for 2013i timezone data integration [1] to JDK9. There is one change in tzdb that affects naming for Asia/Amman timezone: The Jordan switches back to standard time at 00:00 on December 20, 2013. All changes in TimeZoneNames*.java and TimeZoneNames*.properties files are related to this one tzdb change. The list of executed regression test sets: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter test/closed/java/util/Calendar test/closed/java/util/TimeZone All tests gave PASS result. Webrev location: http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.00/ Thank you, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8030822
Re: JDK9 RFR of JDK-8029646: [pack200] should support the new zip64 format.
Alex, I am satisfied. Thanks Kumar Kumar, see my notes inline. On 1/21/14 20:11, Kumar Srinivasan wrote: Alex, Thanks for adding the test, few comments: PackTestZip64.java: 1. compareTwoFile, I would read the entire file into ByteArrayInputStream, compare the total first ie. fast fail, but what you have is also ok. I've tried the approach of reading the entire file into memory and it doesn't seem to speed up the process so much, so i'd left it as it is. 2. generateLargeJar: I would replace lines 126,127 and 128 using for-each loop, by using Collections.listEnumeration e); will make it more compact. Done. 3. Though the test might not take too long on your system, I am concerned it may take too long on our Jprt system. I tested it on JPRT - there's no system on which test takes more than a minute - actually the longest test run time was on the solaris-sparc and it's 44 seconds, so it seems it's Ok. The updated webrev can be found at: http://cr.openjdk.java.net/~kizune/8029646/webrev.03 /Alex Kumar On 1/16/2014 8:21 AM, Alexander Zuev wrote: Sherman, Kumar, i have fixed the glitches you have found and changed the test so it creates a new jar based on the golden.jar content (to have a reasonable set of various data to start with), then adding to it 65536 empty files to test how we cope with such a huge jars. The testing time is less than a 30 seconds on my machine (not the top-of-the-line) so i decided not to bother with conditional testing, lets test our behavior every time in full. The updated webrev can be found at http://cr.openjdk.java.net/~kizune/8029646/webrev.02 /Alex On 1/15/14 21:34, Xueming Shen wrote: On 1/15/14 7:01 AM, Alexander Zuev wrote: Hello, the new webrev with all the typos and comments fixed can be found at http://cr.openjdk.java.net/~kizune/8029646/webrev.01/ /Alex (1) jarmagic can be just a static constant somewhere or a stack variable. not big deal though. (2) the test only tests EOF for s. there is possibility that the newly created has more extra bytes at the end...though in theory this should not happen, it might be better just add an extra line to check the sizes of two first first? (3) the rest of the change looks good, but I agreed with Kumar that you may need to add a regression test for a jar file with 64k entries. otherwise the code for zip64 end is not being tested. the code looks fine, but I would trust a regression test more than my eyes:-) Thanks! -Sherman
RFR JDK 9: 8032502: java.time add @param tags to readObject
Please review this javadoc improvement to add @param tags to readObject Webrev: http://cr.openjdk.java.net/~rriggs/webrev-time-param-8032502/ Thanks, Roger
Re: RFR JDK 9: 8032502: java.time add @param tags to readObject
looks fine Roger as am sure this will make the doclint warnings less On Jan 22, 2014, at 4:26 PM, roger riggs wrote: Please review this javadoc improvement to add @param tags to readObject Webrev: http://cr.openjdk.java.net/~rriggs/webrev-time-param-8032502/ Thanks, Roger Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: RFR JDK 9: 8032502: java.time add @param tags to readObject
On 01/22/2014 01:26 PM, roger riggs wrote:
Please review this javadoc improvement to add @param tags to readObject
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-time-param-8032502/
Thanks, Roger
Hi Roger,
I'll approve this if you either
* replace codeObjectInputStream/code with {@code ObjectInputStream}
* replace codeObjectInputStream/code with stream
Cheers,
-Joe
Aw: JEP 187: Serialization 2.0 Serialization-aware constructors
Am 22.01.2014 um 17:33 schrieb David M. Lloyd david.ll...@redhat.com: The concept of explicit deserialization constructors is interesting and is something I've explored a little bit in the context of JBoss Marshalling. ... The idea with a serialization-aware constructor is that each serializable class constructor can read the stream information itself and initialize fields the normal way, with normal validation. I agree with David. One thing to think about might be to introduce a special kind of constructor by extending the JLS - to introduce a special deserialization constructor that behaves a bit different than normal constructors. Deserialization-constructors are called top-down (java.lang.Object first) - the deserialization code is responsible to call the deserialization-constructors for each individual class. The deserialization-constructor receives information only for deserialized fields that the class owns (not for fields of any superclass or subclass). But: deserialization-constructors should not be callable from normal code. Maybe there could be multiple deserialization constructors - one per serialVersionUID. This should completely eliminate spaghetti code in readObject() and the need for readObject() at all. Another idea is to introduce a kind of protocol how to deal with incompatible class changes or serial-version-uid mismatches. This gets important when existing applications grow: how shall a new field be initialized, when it's not present in input stream? Maybe this could be handled by the deserialization constructor. Regarding the situation when an older implementation reads data from a newer implementation (with more fields or changed fields) ... I think that special situation cannot be handled. But it might be possible to serialize objects explicitly for older versions - for example if the implementation knows that it creating an RPC response for an older client. writeObject() could be replaced with serialization methods - multiple serialization methods could be used to address different versions. A new serialization framework should also add support for classes with factory methods like those with static valueOf(...) methods - maybe in combination to replace readResolve/writeReplace. Serialization should also respect immutable objects like String, Byte/Integer/Long/..., InetAddress, UUID - this reduces the serialized payload and amount of (unnecessary) objects during deserialization. Maybe serialization should move a bit deeper into the JVM itself - to optimize the reflection/unsafe stuff. IMHO the explicit serialFields support should not be supported for serialization 2.0 - maybe I'm wrong, but I do not know any code that uses this (except some core JDK classes) - for me it looks like a workaround to deal with incompatible class changes. Transport and serialization might be separated in serialization 2.0. Current OOS/OIS implementations perform a lot of System.arraycopy operations and allocate a lot of temporary objects (e.g. during string (de)serialization). It should be possible to feed deserialization with ByteBuffers - for example by using NIO. For example: the current internal readPrimitives() method could directly operate on a ByteBuffer without any copy operation - maybe with native support from the JVM. Robert
Re: RFR JDK 9: 8032502: java.time add @param tags to readObject
Thanks for the reminder Joe, I updated the webrev with the 2nd, shorter
version.
Roger
On 1/22/2014 4:33 PM, Joe Darcy wrote:
On 01/22/2014 01:26 PM, roger riggs wrote:
Please review this javadoc improvement to add @param tags to readObject
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-time-param-8032502/
Thanks, Roger
Hi Roger,
I'll approve this if you either
* replace codeObjectInputStream/code with {@code
ObjectInputStream}
* replace codeObjectInputStream/code with stream
Cheers,
-Joe
(7u backport) RFR: 7199674 - (props) user.home property does not return an accessible location in sandboxed environment [macosx]
Hi, I would like to backport this fix from 8 to 7u. https://bugs.openjdk.java.net/browse/JDK-7199674 The source code changes apply cleanly to 7u from the 8 changeset, however the makefile changes needed to be tweaked. makefiles/CompileNativeLibraries.gmk did not exist in 7, so equivalent changes are made in make/java/java/Makefile instead. Since it's not a direct port of the 8 changes, my understanding is that the 7-specific changes should be reviewed. 7u40 webrev is here: http://cr.openjdk.java.net/~bchristi/7199674/7u/webrev.0/ Again, the only difference from the 8 fix is in make/java/java/Makefile. For reference: * JDK 8 changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f81a12fed4d * JDK 8 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020699.html Thanks, -Brent
Re: RFR JDK 9: 8032502: java.time add @param tags to readObject
On 01/22/2014 01:39 PM, roger riggs wrote:
Thanks for the reminder Joe, I updated the webrev with the 2nd,
shorter version.
Ship it :-)
-Joe
Roger
On 1/22/2014 4:33 PM, Joe Darcy wrote:
On 01/22/2014 01:26 PM, roger riggs wrote:
Please review this javadoc improvement to add @param tags to readObject
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-time-param-8032502/
Thanks, Roger
Hi Roger,
I'll approve this if you either
* replace codeObjectInputStream/code with {@code
ObjectInputStream}
* replace codeObjectInputStream/code with stream
Cheers,
-Joe
Re: RFR: JDK-8032012, , String.toLowerCase/toUpperCase performance improvement
Am 22.01.2014 16:20, schrieb Paul Sandoz:
On Jan 21, 2014, at 11:05 PM, Xueming Shen xueming.s...@oracle.com wrote:
On 01/20/2014 09:24 AM, Paul Sandoz wrote:
- it would be nice to get rid of the pseudo goto using the scan labelled
block.
webrev has been updated to remove the pseudo goto by checking the first
against
len after the loop break.
Much for readable :-)
I think, you should compare the performance of both versions on modern + 32-bit
CPUs.
- you might be able to optimize by doing (could depend on the answer to the
next point):
int c = (int)value[i];
int lc = Character.toLowerCase(c);
if (.) { result[i] = (char)lc; } else { return toLowerCaseEx(result, i,
locale, localeDependent); }
- Do you need to check ERROR for the result of toLowerCase?
2586 if (c == Character.ERROR ||
Yes, Character.toLowerCase() should never return ERROR (while the package
private
Character.toUpperCaseEx() will). In theory there is no need to check if the
return
value of Character.toUpperCase(int) min_supplementary_code_point in our loop,
because there is no bmp character returns a supplementary code point as its
lower
case. But since it's a data driven mapping table, there is no guarantee the
unicode
data table is not going to change in the future, so I still keep the check.
In my opinion this check should be subject of JDK's build test, but not of
runtime code.
or:
int c = (int)value[i];
int lc = Character.toLowerCase(c); // is that safe?
if (c '\u03A3' || (c Character.MIN_HIGH_SURROGATE c != 'u03A3' lc
Character.MIN_SUPPLEMENTARY_CODE_POINT))) {
result[i] = (char)lc;
} else {
return toLowerCaseEx(result, i, locale, localeDependent);
}
FWIW i personally find those solutions easier to read, if they are safe w.r.t.
Character.toLowerCase and that annoying greek character.
I would like the 3rd version.
-Ulf
Re: ObjectIn/OutputStream improvements
I found another location in OOS code that might be an optimization point:
In java.io.ObjectOutputStream.BlockDataOutputStream#write(byte[], int, int,
boolean) the first lines look like this:
if (!(copy || blkmode)) { // write directly
drain();
out.write(b, off, len);
return;
}
The block is executed a lot and prevents effective buffering in the internal
byte[] buf field. I've replaced it with
if (!(copy || blkmode)) { // write directly
if (len + pos = MAX_BLOCK_SIZE) {
System.arraycopy(b, off, buf, pos, len);
pos += len;
}
else {
drain();
out.write(b, off, len);
}
return;
}
and it works - at least for our application. I've no idea what that if was
originally for.
Another point of optimization would be to either introduce readResolve() in
primitive wrapper classes (Boolean, Byte, Character, Short, Integer, Long) or
add some support to handle primitive wrapper classes in
java.io.ObjectInputStream#readOrdinaryObject. The current implementation
creates new (senseless?) instances of these wrapper classes. This changes
deserialization semantics (no distinct object references for those classes) -
maybe it should be delayed to serialization 2.0?
-Robert
Am 07.01.2014 um 10:05 schrieb Chris Hegarty chris.hega...@oracle.com:
Did you attach the diffs? I don’t see any attachment, it may be that the
attachment was stripped. Can you try resending inline?
Which optimizations does Hotspot apply?
Is there any documentation available which optimizations Hotspot can perform
and what collecting a garbage object costs?
I know that these are two completely different areas ;)
I was inspecting whether the following code
for (Object o : someArrayList) { ... }
would be faster than
for (int i=0, l=someArrayList.size(); il; i++) { Object
o=someArrayList.get(i); }
for RandomAccessList implementations. The challenge here is not just to track
the CPU time spent creating using the iterator vs. size() get() calls but
also track GC effort (which is at least complicated if not impossible due to
the variety of GC configuration options).
For example:
- Does it help Hotspot to declare parameters/variables as final or can
Hotspot identify that?
- When does Hotspot inline method calls in general and getters/setters
especially?
I think such a piece of documentation (just what Hotspot can do in which
release) would be really helpful when someone tries to optimize code - want to
say: the question is: Is something worth to spend time on or is this special
situation handled by Hotspot?
-Robert
(7u backport) RFR: 7199674 - (props) user.home property does not return an accessible location in sandboxed environment [macosx]
(forgot to include macosx-port-...@openjdk.java.net) Hi, I would like to backport this fix from 8 to 7u. https://bugs.openjdk.java.net/browse/JDK-7199674 The source code changes apply cleanly to 7u from the 8 changeset, however the makefile changes needed to be tweaked. makefiles/CompileNativeLibraries.gmk did not exist in 7, so equivalent changes are made in make/java/java/Makefile instead. Since it's not a direct port of the 8 changes, my understanding is that the 7-specific changes should be reviewed. 7u40 webrev is here: http://cr.openjdk.java.net/~bchristi/7199674/7u/webrev.0/ Again, the only difference from the 8 fix is in make/java/java/Makefile. For reference: * JDK 8 changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5f81a12fed4d * JDK 8 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/020699.html Thanks, -Brent
Re: Which optimizations does Hotspot apply?
You can start here:
wikis.oracle.com/display/hotspotinternals/performancetechniques
Sent from my phone
On Jan 22, 2014 5:37 PM, Robert Stupp sn...@snazy.de wrote:
Is there any documentation available which optimizations Hotspot can
perform and what collecting a garbage object costs?
I know that these are two completely different areas ;)
I was inspecting whether the following code
for (Object o : someArrayList) { ... }
would be faster than
for (int i=0, l=someArrayList.size(); il; i++) { Object
o=someArrayList.get(i); }
for RandomAccessList implementations. The challenge here is not just to
track the CPU time spent creating using the iterator vs. size() get()
calls but also track GC effort (which is at least complicated if not
impossible due to the variety of GC configuration options).
For example:
- Does it help Hotspot to declare parameters/variables as final or can
Hotspot identify that?
- When does Hotspot inline method calls in general and getters/setters
especially?
I think such a piece of documentation (just what Hotspot can do in which
release) would be really helpful when someone tries to optimize code - want
to say: the question is: Is something worth to spend time on or is this
special situation handled by Hotspot?
-Robert
Re: JDK 9 RFR of 8032397: Remove sun.misc.Ref
On 1/21/2014 5:17 PM, Joe Darcy wrote: Hi Alan, Updated webrev at http://cr.openjdk.java.net/~darcy/8032397.1/ Looks good to me. @see in sun.misc.Ref removed. Regression tests updated to not refer to sun.misc.Ref. I looked at the use of Ref in jhat and it is only used if java.lang.ref.Reference is not found reflectively, so I think the existing code can stay in place. I think it's actually better to update jhat and take out the fallback to lookup sun.misc.Ref class as it was there to handle 1.1.x heap dump so that sun.misc.Ref is entirely removed. Mandy
Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9
I need help. I am trying to do control build in JPRT after I merged latest jdk9 source: http://hg.openjdk.java.net/jdk9/jdk9 to latest ppc64 sources: http://hg.openjdk.java.net/ppc-aix-port/stage-9 I have build failure on Mac OS X (on other platforms it passed). See the output below. I tried different JPRT queues - the same problem. During sync I had to merge common/autoconf/toolchain.m4 (merged automatically) and regenerate generated-configure.sh. The latest changes to toolchain.m4 was: http://hg.openjdk.java.net/jdk9/jdk9/rev/50669e45cec4 Next jdk files merge was resolved automatically: merging make/CompileDemos.gmk merging src/solaris/bin/java_md_solinux.c merging test/ProblemList.txt merging test/tools/launcher/ExecutionEnvironment.java 291 files updated, 4 files merged, 14 files removed, 0 files unresolved Thanks, Vladimir The build failure on Mac OS X: Cleaning up: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src Outputting classes to: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src Searching for bridged frameworks in: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/bridge found 3 frameworks Parsing XML Exception in thread main java.lang.UnsatisfiedLinkError: no JObjC in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1119) at com.apple.jobjc.Coder.clinit(Coder.java:60) at com.apple.internal.jobjc.generator.model.coders.CoderDescriptor.clinit(CoderDescriptor.java:38) at com.apple.internal.jobjc.generator.model.types.NType$NPrimitive.init(NType.java:117) at com.apple.internal.jobjc.generator.model.types.Type.clinit(Type.java:57) at com.apple.internal.jobjc.generator.model.Element.init(Element.java:47) at com.apple.internal.jobjc.generator.model.Framework.init(Framework.java:99) at com.apple.internal.jobjc.generator.FrameworkGenerator.parseFrameworksFrom(FrameworkGenerator.java:56) at com.apple.internal.jobjc.generator.Generator.main(Generator.java:57) make[2]: *** [/opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/_the.generator] Error 1 make[1]: *** [gensrc-only] Error 2 make: *** [jdk-only] Error 2
hg: jdk8/tl/jdk: 8031825: OCSP client can't find responder cert if it uses a different subject key id algorithm than responderID
Changeset: 57c26829deb6 Author:mullan Date: 2014-01-22 19:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57c26829deb6 8031825: OCSP client can't find responder cert if it uses a different subject key id algorithm than responderID Reviewed-by: vinnie, xuelei ! src/share/classes/sun/security/provider/certpath/OCSPResponse.java
Re: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9
I haven't tried this, but Tim Bell mentioned this in an email inquiry I had earlier, This will be cured when the fix for 8021266 is pushed to JDK 9 (see attached). In the meantime, the workaround in JPRT is to submit your JDK 9 jobs with '-bootproduct jdk7u7' since the 7u51 release can not serve as a boot JDK. Cheers, Henry On 01/22/2014 03:53 PM, Vladimir Kozlov wrote: I need help. I am trying to do control build in JPRT after I merged latest jdk9 source: http://hg.openjdk.java.net/jdk9/jdk9 to latest ppc64 sources: http://hg.openjdk.java.net/ppc-aix-port/stage-9 I have build failure on Mac OS X (on other platforms it passed). See the output below. I tried different JPRT queues - the same problem. During sync I had to merge common/autoconf/toolchain.m4 (merged automatically) and regenerate generated-configure.sh. The latest changes to toolchain.m4 was: http://hg.openjdk.java.net/jdk9/jdk9/rev/50669e45cec4 Next jdk files merge was resolved automatically: merging make/CompileDemos.gmk merging src/solaris/bin/java_md_solinux.c merging test/ProblemList.txt merging test/tools/launcher/ExecutionEnvironment.java 291 files updated, 4 files merged, 14 files removed, 0 files unresolved Thanks, Vladimir The build failure on Mac OS X: Cleaning up: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src Outputting classes to: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src Searching for bridged frameworks in: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/bridge found 3 frameworks Parsing XML Exception in thread main java.lang.UnsatisfiedLinkError: no JObjC in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1119) at com.apple.jobjc.Coder.clinit(Coder.java:60) at com.apple.internal.jobjc.generator.model.coders.CoderDescriptor.clinit(CoderDescriptor.java:38) at com.apple.internal.jobjc.generator.model.types.NType$NPrimitive.init(NType.java:117) at com.apple.internal.jobjc.generator.model.types.Type.clinit(Type.java:57) at com.apple.internal.jobjc.generator.model.Element.init(Element.java:47) at com.apple.internal.jobjc.generator.model.Framework.init(Framework.java:99) at com.apple.internal.jobjc.generator.FrameworkGenerator.parseFrameworksFrom(FrameworkGenerator.java:56) at com.apple.internal.jobjc.generator.Generator.main(Generator.java:57) make[2]: *** [/opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/_the.generator] Error 1 make[1]: *** [gensrc-only] Error 2 make: *** [jdk-only] Error 2
Re: Which optimizations does Hotspot apply?
Remi,
Regarding your last point - picking correct data structures and algos is of
course step 1 in any optimization. But, provided that's taken care of,
there're plausible reasons to attempt to cater to hotspot as well (if
that's the jvm in use). There are certainly code shapes that it prefers.
There's a whole slew of inlining heuristics and rules to be aware of.
There's a set of intrinsics, in some cases covering only a subset of an API
of a class. These things are always subject to change, but saying never
worth it isn't right either :).
Sent from my phone
On Jan 22, 2014 6:38 PM, Remi Forax fo...@univ-mlv.fr wrote:
On 01/22/2014 11:37 PM, Robert Stupp wrote:
Is there any documentation available which optimizations Hotspot can
perform and what collecting a garbage object costs?
I know that these are two completely different areas ;)
I was inspecting whether the following code
for (Object o : someArrayList) { ... }
would be faster than
for (int i=0, l=someArrayList.size(); il; i++) { Object
o=someArrayList.get(i); }
for RandomAccessList implementations. The challenge here is not just to
track the CPU time spent creating using the iterator vs. size() get()
calls but also track GC effort (which is at least complicated if not
impossible due to the variety of GC configuration options).
For a long time, using a for with an index (if you are *sure* that it's an
ArrayList) was faster.
With latest jdk8, it's not true anymore.
(and most of the time the iterator object is not created anymore at least
with jdk7+).
For example:
- Does it help Hotspot to declare parameters/variables as final or can
Hotspot identify that?
no, it's an urban myth.
You can test it by yourself, if you declare a local variable final or not
the exact same bytecode is produced by javac. The keyword final for a local
variable (or a parameter) is not stored in the bytecode.
BTW, final was introduced in 1.1 mostly to allow to capture the value of a
variable to be used by an anonymous class, Java 8 doesn't require this kind
of variable to be declared final anymore.
- When does Hotspot inline method calls in general and getters/setters
especially?
In general, up to a depth of 10 by default and 1 for a recursive method.
Roughly, a method call is not inlined either if the call is virtual and
can call too many implementations or if the generated assembly code will be
too big.
I think such a piece of documentation (just what Hotspot can do in which
release) would be really helpful when someone tries to optimize code - want
to say: the question is: Is something worth to spend time on or is this
special situation handled by Hotspot?
It never worth it.
Choose the right algorithms and shape your data to be easily consumed by
your algorithms is enough.
-Robert
Rémi
Re: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9
Thank you very much, Henry The suggested workaround helped! Thanks, Vladimir On 1/22/14 4:18 PM, Henry Jen wrote: I haven't tried this, but Tim Bell mentioned this in an email inquiry I had earlier, This will be cured when the fix for 8021266 is pushed to JDK 9 (see attached). In the meantime, the workaround in JPRT is to submit your JDK 9 jobs with '-bootproduct jdk7u7' since the 7u51 release can not serve as a boot JDK. Cheers, Henry On 01/22/2014 03:53 PM, Vladimir Kozlov wrote: I need help. I am trying to do control build in JPRT after I merged latest jdk9 source: http://hg.openjdk.java.net/jdk9/jdk9 to latest ppc64 sources: http://hg.openjdk.java.net/ppc-aix-port/stage-9 I have build failure on Mac OS X (on other platforms it passed). See the output below. I tried different JPRT queues - the same problem. During sync I had to merge common/autoconf/toolchain.m4 (merged automatically) and regenerate generated-configure.sh. The latest changes to toolchain.m4 was: http://hg.openjdk.java.net/jdk9/jdk9/rev/50669e45cec4 Next jdk files merge was resolved automatically: merging make/CompileDemos.gmk merging src/solaris/bin/java_md_solinux.c merging test/ProblemList.txt merging test/tools/launcher/ExecutionEnvironment.java 291 files updated, 4 files merged, 14 files removed, 0 files unresolved Thanks, Vladimir The build failure on Mac OS X: Cleaning up: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src Outputting classes to: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/src Searching for bridged frameworks in: /opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/bridge found 3 frameworks Parsing XML Exception in thread main java.lang.UnsatisfiedLinkError: no JObjC in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857) at java.lang.Runtime.loadLibrary0(Runtime.java:870) at java.lang.System.loadLibrary(System.java:1119) at com.apple.jobjc.Coder.clinit(Coder.java:60) at com.apple.internal.jobjc.generator.model.coders.CoderDescriptor.clinit(CoderDescriptor.java:38) at com.apple.internal.jobjc.generator.model.types.NType$NPrimitive.init(NType.java:117) at com.apple.internal.jobjc.generator.model.types.Type.clinit(Type.java:57) at com.apple.internal.jobjc.generator.model.Element.init(Element.java:47) at com.apple.internal.jobjc.generator.model.Framework.init(Framework.java:99) at com.apple.internal.jobjc.generator.FrameworkGenerator.parseFrameworksFrom(FrameworkGenerator.java:56) at com.apple.internal.jobjc.generator.Generator.main(Generator.java:57) make[2]: *** [/opt/jprt/T/P1/223112.vkozlov/s/build/macosx-x86_64-normal-server-release/jdk/gensrc_jobjc/_the.generator] Error 1 make[1]: *** [gensrc-only] Error 2 make: *** [jdk-only] Error 2
Re: i18n dev RFR: 8030822: (tz) Support tzdata2013i
Hi Aleksej, I think this one is the first tzdata change for JDK9. So I'd suggest that all the TimeZoneNames*.properties files, which were temporarily created for the translation work, be removed. Thanks, Masayoshi On 1/21/2014 10:17 PM, Aleksej Efimov wrote: Hi, Can I have a review for 2013i timezone data integration [1] to JDK9. There is one change in tzdb that affects naming for Asia/Amman timezone: The Jordan switches back to standard time at 00:00 on December 20, 2013. All changes in TimeZoneNames*.java and TimeZoneNames*.properties files are related to this one tzdb change. The list of executed regression test sets: test/sun/util/calendar test/java/util/Calendar test/sun/util/resources/TimeZone test/sun/util/calendar test/java/util/TimeZone test/java/time test/java/util/Formatter test/closed/java/util/Calendar test/closed/java/util/TimeZone All tests gave PASS result. Webrev location: http://cr.openjdk.java.net/~aefimov/8030822/9/webrev.00/ Thank you, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8030822
