Re: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9
Hi, I've reported this last week on the build-dev list (Build error on Mac with 7u51 boot jdk because JObjC.jar was removed from 7u51, http://mail.openjdk.java.net/pipermail/build-dev/2014-January/011566.html), but didn't get any answer yet. The only workaround seems to be to use an older boot JDK as already mentioned by Henry. Unfortunately the problem is a little obscure because both, 8021271 which caused the problem as well as 8021266 which according to Henry will solve the problem are not visible because they are considered security relevant. Regards, Volker On Thu, Jan 23, 2014 at 1:18 AM, Henry Jen henry@oracle.com 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: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9
On 23.01.2014 3:53, 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 Looks like the problem is that 8032348 is not pushed to the master workspace of jdk9, but the bootjdk have this fix. 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 -- Best regards, Sergey.
Re: Problem to build jdk on Mac OS X from ppc64 stage after sync with jdk9
On 2014-01-23 09:32, Sergey Bylokhov wrote: On 23.01.2014 3:53, 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 Looks like the problem is that 8032348 is not pushed to the master workspace of jdk9, but the bootjdk have this fix. This is correct. The bootjdk in this case is the latest build of jdk8, which has the fix. As soon as the fix is pushed to 9, this will resolve itself. /Erik
Re: JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013
Hi Miran, did you get any response on this yet? MartiNG On 17/01/14 10:57, Miroslav Kos wrote: Hi Steve and Alan, I just reminding this issue - I have no response from anybody yet and it would really simplify our integration if I could handle copyright years inconsistencies this way - I see this issue in many jdk branches and these each-branch-different changes make each integration much more pain. Thanks for any idea on this. Miran On 10/01/14 18:05, Miroslav Kos wrote: Hi, this is about fixing copyright years for jdk8 (!); the incorrect years found for both 2012 and 2013, so not to confuse script jdk8/make/scripts/update_copyright_year.sh it is necessary to use option -d date for commit. I tested that and it seems to work perfect. I used following: [2012 modifications] hg commit -u mkos -l ../2012-msg.txt -d 2012-12-30 [2013 modifications] hg commit -u mkos -l ../2013-msg.txt -d 2013-12-30 When commits performed with past date, update_copyright_year.sh script finds those in proper years. Since I am not familiar with using webrev for pushing changes, I exported both revisions into separate patches: 2012: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012.patch 2013: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013.patch all changes webrev: http://cr.openjdk.java.net/~mkos/8029237/webrev-all.00/ (upload still in progress, I hope it doesn't take more than 30 mins) bug: https://bugs.openjdk.java.net/browse/JDK-8029237 Regards Miran -- Martin Grebac, SW Engineering Manager Oracle Czech, Prague
Re: JDK8 RFR JDK-8029237 Update copyright year to match last edit in jdk8 jaxws repository for 2013
On 23 Jan 2014, at 08:53, Martin Grebac martin.gre...@oracle.com wrote: Hi Miran, did you get any response on this yet? MartiNG On 17/01/14 10:57, Miroslav Kos wrote: Hi Steve and Alan, I just reminding this issue - I have no response from anybody yet and it would really simplify our integration if I could handle copyright years inconsistencies this way - I see this issue in many jdk branches and these each-branch-different changes make each integration much more pain. Thanks for any idea on this. Miran On 10/01/14 18:05, Miroslav Kos wrote: Hi, this is about fixing copyright years for jdk8 (!); the incorrect years found for both 2012 and 2013, so not to confuse script jdk8/make/scripts/update_copyright_year.sh it is necessary to use option -d date for commit. I tested that and it seems to work perfect. I used following: [2012 modifications] hg commit -u mkos -l ../2012-msg.txt -d 2012-12-30 [2013 modifications] hg commit -u mkos -l ../2013-msg.txt -d 2013-12-30 When commits performed with past date, update_copyright_year.sh script finds those in proper years. Since I am not familiar with using webrev for pushing changes, I exported both revisions into separate patches: 2012: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2012.patch I skimmed the patch and it looks ok to me. Trivially, it contains a 2013 update (which it should probably be in the 2013 patch) diff -r 91f5c542ccad -r d6aec26c9771 make/Makefile --- a/make/Makefile Fri Jan 03 11:54:55 2014 -0800 +++ b/make/Makefile Sun Dec 30 00:00:00 2012 +0100 @@ -1,5 +1,5 @@ # -# Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. # 2013: http://cr.openjdk.java.net/~mkos/8029237/copyrights-2013.patch Looks ok to me. -Chris. all changes webrev: http://cr.openjdk.java.net/~mkos/8029237/webrev-all.00/ (upload still in progress, I hope it doesn't take more than 30 mins) bug: https://bugs.openjdk.java.net/browse/JDK-8029237 Regards Miran -- Martin Grebac, SW Engineering Manager Oracle Czech, Prague
Re: RFR: 8028816: Add value-type notice to Optional* classes
On 12/03/2013 11:21 PM, Mike Duigou wrote: There's been a discussion on the lambda spec experts list (http://mail.openjdk.java.net/pipermail/lambda-spec-experts/) about adding a notice to the Optional classes about implications of their likely future as values. This discussion recently completed so now there's a doc patch to review: http://cr.openjdk.java.net/~mduigou/JDK-8028816/0/webrev/ I have already reviewed this but will hold off pushing it for a few hours in case someone notices a mistake that I did not. Would it make sense to have an annotation (with class file retention) to express this? -- Florian Weimer / Red Hat Product Security Team
hg: jdk8/tl/jdk: 8032190: Specifications of stream flatMap methods should require mapped streams to be closed
Changeset: 68eb0c55a8c0 Author:psandoz Date: 2014-01-21 10:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68eb0c55a8c0 8032190: Specifications of stream flatMap methods should require mapped streams to be closed Reviewed-by: chegar, alanb ! src/share/classes/java/util/stream/DoubleStream.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/LongStream.java ! src/share/classes/java/util/stream/Stream.java
Re: JEP 187: Serialization 2.0
On 22 Jan 2014, at 15:14, Florian Weimer fwei...@redhat.com wrote: 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. Sorry, but I may still be missing your point. From my reading of the code, CCE will only be thrown if the object being deserialized contains a field with a type that does not match the type of the similarly named field in the class loaded by the deserializing context. If there is no value assigned to said field, then it is just ignored. Also, if the type of a field changes, from one version of the class to another, but the name remains the same, then the serialVersionUID will differ. Are you thinking specifically about corrupt/malicious streams, or evolving serializable types? Or a performance optimisation? -Chris. -- Florian Weimer / Red Hat Product Security Team
Re: JEP 187: Serialization 2.0 Serialization-aware constructors
Hi David, This is a nice summary of how object deserialization is working today, and some interesting ideas around serialisation-aware constructors. It seems there is just too much magic in the construction of deserialized objects. All the field values required to fully construct the object are known, or are in the stream, but the instance is constructed without giving them any consideration, and the stuffing happens after the fact. It would seem that if these fields were made available to a “special” deserializer that the class being reconstructed would have the possibility of constructing itself in a more normal manner ( assuming constructor cooperation up the class hierarchy ). -Chris. On 22 Jan 2014, at 16:33, David M. Lloyd david.ll...@redhat.com wrote: 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: (7u backport) RFR: 7199674 - (props) user.home property does not return an accessible location in sandboxed environment [macosx]
On 22/01/2014 21:48, Brent Christian wrote: 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. I looked at the make file changes (as that it the only part that is different) and it okay to me. You'll need to request approval on jdk7u-dev and probably best to do that soon if you are looking for this in 7u60 as I think they are close to forking the stabilization forest. -Alan
RFR: 8028816: Add value-type notice to Optional* classes
Florian, it's an idea I also broached but did not receive any feedback: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-December/002585.html The only downside to adding the annotation is that it makes it the official way to denote a value type. Based on some JEPs and Lambda mailings, I think there's some heavy discussions behind the scenes to explore this design space. I don't know if committing to an annotation at this point is the right solution. -- Cheers, Paul * There's been a discussion on the lambda spec experts list (http://mail.openjdk.java.net/pipermail/lambda-spec-experts/ http://mail.openjdk.java.net/pipermail/lambda-spec-experts/) about adding a notice to the Optional classes about implications of their likely future as values. This discussion recently completed so now there's a doc patch to review: ** http://cr.openjdk.java.net/~mduigou/JDK-8028816/0/webrev/ http://cr.openjdk.java.net/%7Emduigou/JDK-8028816/0/webrev/ ** I have already reviewed this but will hold off pushing it for a few hours in case someone notices a mistake that I did not. * Would it make sense to have an annotation (with class file retention) to express this? -- Florian Weimer / Red Hat Product Security Team
Re: RFR: 8028816: Add value-type notice to Optional* classes
A future version of Java will hopefully have value types. The disclaimers about value-based are intended as a stake in the ground, to preserve the option to migrate these specific new-to-Java-8 types to value types in the future. (Older sort-of-valueish-like-but-not-quite types, like Integer, are a hopeless cause.) When value type is a real thing, it will have linguistic support. Until then, he best we can do is capture the design intent for specific library classes in their specification to preserve clarity and flexibility. On Jan 23, 2014, at 11:13 AM, Paul Benedict wrote: Florian, it's an idea I also broached but did not receive any feedback: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-December/002585.html The only downside to adding the annotation is that it makes it the official way to denote a value type. Based on some JEPs and Lambda mailings, I think there's some heavy discussions behind the scenes to explore this design space. I don't know if committing to an annotation at this point is the right solution. -- Cheers, Paul * There's been a discussion on the lambda spec experts list (http://mail.openjdk.java.net/pipermail/lambda-spec-experts/ http://mail.openjdk.java.net/pipermail/lambda-spec-experts/) about adding a notice to the Optional classes about implications of their likely future as values. This discussion recently completed so now there's a doc patch to review: ** http://cr.openjdk.java.net/~mduigou/JDK-8028816/0/webrev/ http://cr.openjdk.java.net/%7Emduigou/JDK-8028816/0/webrev/ ** I have already reviewed this but will hold off pushing it for a few hours in case someone notices a mistake that I did not. * Would it make sense to have an annotation (with class file retention) to express this? -- Florian Weimer / Red Hat Product Security Team
Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently
Hi Peter, i have modified your code from
r = pending;
if (r != null) {
..
TO
if (pending != null) {
r = pending;
This is because the r is used later in the code and must not be assigned
pending unless it is not null(this was as is earlier). The new webrev is
posted here
http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/
. I ran a 1000 run and no failures so far, however i would like to run a
couple more 1000 runs to assert the fix.
PS: The description section of JEP-122
(http://openjdk.java.net/jeps/122) says meta-data would be in native
memory(not heap).
--
Thanks
kalyan
Ph: (408)-585-8040
On 1/21/14, 2:31 PM, Peter Levart wrote:
On 01/21/2014 07:17 PM, srikalyan wrote:
Hi Peter/David, catching up after long weekend. Why would there be an
OOME in object heap due to class loading in perm gen space ?
The perm gen is not a problem her (JDK 8 does not have it and we see
OOME on JDK8 too). Each time a class is loaded, new java.lang.Class
object is allocated on heap.
Regards, Peter
Please correct if i am missing something here. Meanwhile i will give
the version of Reference Handler you both agreed on a try.
--
Thanks
kalyan
Ph: (408)-585-8040
On 1/21/14, 7:24 AM, Peter Levart wrote:
On 01/21/2014 07:54 AM, Peter Levart wrote:
*[Loaded sun.misc.Cleaner from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]*
[Loaded java.io.ByteArrayInputStream from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]
[Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule
from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]
...
I'm on linux, 64bit and using official EA build 121 of JDK 8...
But if I try with JDK 7u45, I don't see it.
So what changed between JDK 7 and JDK 8?
I suspect the following: 8007572: Replace existing jdk timezone data
at java.home/lib/zi with JSR310's tzdb
Regards, Peter
[9] RFR (XXS): 8031043: ClassValue's backing map should have a smaller initial size
https://bugs.openjdk.java.net/browse/JDK-8031043 http://cr.openjdk.java.net/~twisti/8031043/webrev.00 8031043: ClassValue's backing map should have a smaller initial size Reviewed-by: The current initial size for ClassValue's backing WeakHashMap (ClassValueMap) is: private static final int INITIAL_ENTRIES = 32; This is too big and wastes a lot of memory. Usually a dynamic language or other users of ClassValue associate only one value with a Class. Even if users need more entries it's better to start small and grow as needed since adding new values to a Class is a one-time thing and not performance critical. Here is some discussion on the mlvm-dev list: http://mail.openjdk.java.net/pipermail/mlvm-dev/2014-January/005597.html
[8011944] Sort fails with ArrayIndexOutOfBoundsException
Hello!
This is a simple backport from 8 to 7.
Looking for a review of this even though it only requires a testcase
change due to the use of lambda expressions.
Since this is the first of these I've encountered I thought I better
play it safe, but generally speaking, are we ok
to skip the review process for backports like this? (minor lambda
related testcase changes - if the lambda's are in the actual fix it
probably makes sense to re-review).
The fix:
src/share/classes/java/util/ComparableTimSort.java
src/share/classes/java/util/TimSort.java
applied with no modification to 7
The only simple change was to replace a lambda expression in test case
test/java/util/Arrays/TimSortStackSize.java:
Arrays.sort(genData(), Integer::compare);
got replaced with
Arrays.sort(genData(),
new java.util.ComparatorInteger() {
public int compare(Integer a1, Integer a2){
return Integer.compare(a1.intValue(), a2.intValue());
}
});
Jdk bug:
https://bugs.openjdk.java.net/browse/JDK-8011944
Original fix for 8:
http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/07585a2483fa
Fix for 7:
http://cr.openjdk.java.net/~miroslawzn/801144/webrev.01/
Thank you
Miroslaw
Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently
Hi Peter/David, we have 2000 runs without a single failure.
--
Thanks
kalyan
Ph: (408)-585-8040
On 1/23/14, 12:10 PM, srikalyan wrote:
Hi Peter, i have modified your code from
r = pending;
if (r != null) {
..
TO
if (pending != null) {
r = pending;
This is because the r is used later in the code and must not be
assigned pending unless it is not null(this was as is earlier). The
new webrev is posted here
http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/
. I ran a 1000 run and no failures so far, however i would like to run
a couple more 1000 runs to assert the fix.
PS: The description section of JEP-122
(http://openjdk.java.net/jeps/122) says meta-data would be in native
memory(not heap).
--
Thanks
kalyan
Ph: (408)-585-8040
On 1/21/14, 2:31 PM, Peter Levart wrote:
On 01/21/2014 07:17 PM, srikalyan wrote:
Hi Peter/David, catching up after long weekend. Why would there be
an OOME in object heap due to class loading in perm gen space ?
The perm gen is not a problem her (JDK 8 does not have it and we see
OOME on JDK8 too). Each time a class is loaded, new java.lang.Class
object is allocated on heap.
Regards, Peter
Please correct if i am missing something here. Meanwhile i will give
the version of Reference Handler you both agreed on a try.
--
Thanks
kalyan
Ph: (408)-585-8040
On 1/21/14, 7:24 AM, Peter Levart wrote:
On 01/21/2014 07:54 AM, Peter Levart wrote:
*[Loaded sun.misc.Cleaner from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]*
[Loaded java.io.ByteArrayInputStream from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]
[Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule
from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]
...
I'm on linux, 64bit and using official EA build 121 of JDK 8...
But if I try with JDK 7u45, I don't see it.
So what changed between JDK 7 and JDK 8?
I suspect the following: 8007572: Replace existing jdk timezone
data at java.home/lib/zi with JSR310's tzdb
Regards, Peter
Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently
On 24/01/2014 6:10 AM, srikalyan wrote:
Hi Peter, i have modified your code from
r = pending;
if (r != null) {
..
TO
if (pending != null) {
r = pending;
This is because the r is used later in the code and must not be assigned
pending unless it is not null(this was as is earlier).
If r is null, because pending is null then you perform the wait() and
then continue - back to the top of the loop. There is no bug in Peter's
code.
The new webrev is
posted here
http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/
. I ran a 1000 run and no failures so far, however i would like to run a
couple more 1000 runs to assert the fix.
PS: The description section of JEP-122
(http://openjdk.java.net/jeps/122) says meta-data would be in native
memory(not heap).
The class_mirror is a Java object not meta-data.
David
--
Thanks
kalyan
Ph: (408)-585-8040
On 1/21/14, 2:31 PM, Peter Levart wrote:
On 01/21/2014 07:17 PM, srikalyan wrote:
Hi Peter/David, catching up after long weekend. Why would there be an
OOME in object heap due to class loading in perm gen space ?
The perm gen is not a problem her (JDK 8 does not have it and we see
OOME on JDK8 too). Each time a class is loaded, new java.lang.Class
object is allocated on heap.
Regards, Peter
Please correct if i am missing something here. Meanwhile i will give
the version of Reference Handler you both agreed on a try.
--
Thanks
kalyan
Ph: (408)-585-8040
On 1/21/14, 7:24 AM, Peter Levart wrote:
On 01/21/2014 07:54 AM, Peter Levart wrote:
*[Loaded sun.misc.Cleaner from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]*
[Loaded java.io.ByteArrayInputStream from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]
[Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule
from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]
...
I'm on linux, 64bit and using official EA build 121 of JDK 8...
But if I try with JDK 7u45, I don't see it.
So what changed between JDK 7 and JDK 8?
I suspect the following: 8007572: Replace existing jdk timezone data
at java.home/lib/zi with JSR310's tzdb
Regards, Peter
Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently
Hi David, yes thats right, only benefit i see is we can avoid assignment
to 'r' if pending is null.
--
Thanks
kalyan
On 1/23/14 4:33 PM, David Holmes wrote:
On 24/01/2014 6:10 AM, srikalyan wrote:
Hi Peter, i have modified your code from
r = pending;
if (r != null) {
..
TO
if (pending != null) {
r = pending;
This is because the r is used later in the code and must not be assigned
pending unless it is not null(this was as is earlier).
If r is null, because pending is null then you perform the wait() and
then continue - back to the top of the loop. There is no bug in
Peter's code.
The new webrev is
posted here
http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/
. I ran a 1000 run and no failures so far, however i would like to run a
couple more 1000 runs to assert the fix.
PS: The description section of JEP-122
(http://openjdk.java.net/jeps/122) says meta-data would be in native
memory(not heap).
The class_mirror is a Java object not meta-data.
David
--
Thanks
kalyan
Ph: (408)-585-8040
On 1/21/14, 2:31 PM, Peter Levart wrote:
On 01/21/2014 07:17 PM, srikalyan wrote:
Hi Peter/David, catching up after long weekend. Why would there be an
OOME in object heap due to class loading in perm gen space ?
The perm gen is not a problem her (JDK 8 does not have it and we see
OOME on JDK8 too). Each time a class is loaded, new java.lang.Class
object is allocated on heap.
Regards, Peter
Please correct if i am missing something here. Meanwhile i will give
the version of Reference Handler you both agreed on a try.
--
Thanks
kalyan
Ph: (408)-585-8040
On 1/21/14, 7:24 AM, Peter Levart wrote:
On 01/21/2014 07:54 AM, Peter Levart wrote:
*[Loaded sun.misc.Cleaner from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]*
[Loaded java.io.ByteArrayInputStream from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]
[Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule
from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]
...
I'm on linux, 64bit and using official EA build 121 of JDK 8...
But if I try with JDK 7u45, I don't see it.
So what changed between JDK 7 and JDK 8?
I suspect the following: 8007572: Replace existing jdk timezone data
at java.home/lib/zi with JSR310's tzdb
Regards, Peter
Re: Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently
On 24/01/2014 11:53 AM, srikalyan chandrashekar wrote:
Hi David, yes thats right, only benefit i see is we can avoid assignment
to 'r' if pending is null.
I'm okay with either version.
David
--
Thanks
kalyan
On 1/23/14 4:33 PM, David Holmes wrote:
On 24/01/2014 6:10 AM, srikalyan wrote:
Hi Peter, i have modified your code from
r = pending;
if (r != null) {
..
TO
if (pending != null) {
r = pending;
This is because the r is used later in the code and must not be assigned
pending unless it is not null(this was as is earlier).
If r is null, because pending is null then you perform the wait() and
then continue - back to the top of the loop. There is no bug in
Peter's code.
The new webrev is
posted here
http://cr.openjdk.java.net/~srikchan/Regression/JDK-8022321_OOMEInReferenceHandler-webrev-V2/
. I ran a 1000 run and no failures so far, however i would like to run a
couple more 1000 runs to assert the fix.
PS: The description section of JEP-122
(http://openjdk.java.net/jeps/122) says meta-data would be in native
memory(not heap).
The class_mirror is a Java object not meta-data.
David
--
Thanks
kalyan
Ph: (408)-585-8040
On 1/21/14, 2:31 PM, Peter Levart wrote:
On 01/21/2014 07:17 PM, srikalyan wrote:
Hi Peter/David, catching up after long weekend. Why would there be an
OOME in object heap due to class loading in perm gen space ?
The perm gen is not a problem her (JDK 8 does not have it and we see
OOME on JDK8 too). Each time a class is loaded, new java.lang.Class
object is allocated on heap.
Regards, Peter
Please correct if i am missing something here. Meanwhile i will give
the version of Reference Handler you both agreed on a try.
--
Thanks
kalyan
Ph: (408)-585-8040
On 1/21/14, 7:24 AM, Peter Levart wrote:
On 01/21/2014 07:54 AM, Peter Levart wrote:
*[Loaded sun.misc.Cleaner from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]*
[Loaded java.io.ByteArrayInputStream from
/home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]
[Loaded sun.util.calendar.ZoneInfoFile$ZoneOffsetTransitionRule
from /home/peter/Apps64/jdk1.8.0-ea-b121/jre/lib/rt.jar]
...
I'm on linux, 64bit and using official EA build 121 of JDK 8...
But if I try with JDK 7u45, I don't see it.
So what changed between JDK 7 and JDK 8?
I suspect the following: 8007572: Replace existing jdk timezone data
at java.home/lib/zi with JSR310's tzdb
Regards, Peter
RFR: JDK-8032050: TEST_BUG: java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java fails intermittently
Hi All Could you review the bug fix for JDK-8032050. http://cr.openjdk.java.net/~tyan/JDK-8032050/webrev.00/ Description: This rare happened failure caused because when RMID starts. It don't guarantee sun.rmi.server.Activation.startActivation finishes. Fix by adding a iterative getSystem with a 5 seconds timeout. Thank you. Tristan
Re: Question about the bug https://bugs.openjdk.java.net/browse/JDK-8031179
Hi Stuart, Thanks for the suggestion! sorry for reply this mail late as i was busy on other tasks The webrev has been in the internal review process. Based on the suggestion, here is a summary of changes: 1. Add othervm options to tests: java/rmi/Naming/DefaultRegistryPort.java java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java java/rmi/Naming/LookupNameWithColon.java java/rmi/server/UnicastRemoteObject/exportObject/GcDuringExport.java sun/rmi/rmic/RMIGenerator/RmicDefault.java java/rmi/MarshalledObject/compare/Compare.java java/rmi/MarshalledObject/compare/HashCode.java 2. Remove java/rmi and sun/rmi from othervm.dirs of TEST.ROOT 3. Filed a another bug https://bugs.openjdk.java.net/browse/JDK-8032629 for exclusiveAccess.dirs Thanks, Eric On 2014/1/18 8:45, Stuart Marks wrote: Hi Eric, Thanks for doing the analysis of the tests that need /othervm. The list of tests that don't need /othervm looks good. One subtlety is this one: java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.java Most activation tests do need /othervm, but this one doesn't, since all it does is create an ActivationGroupDesc instance, which has no side effects. This is unusual for the activation APIs, since most of them are quite intertwined with the rest of the activation subsystem. So, for this test, the lack of /othervm warrants a comment explaining why /othervm is unnecessary. Regarding merging of the tests java/rmi/MarshalledObject/compare/Compare.java and HashCode.java, this is fairly subtle and not obviously wrong, but it's not obviously right either. Note that different jtreg tests -- even in agentvm or samevm mode -- load the test class in a fresh classloader, which means that the statics are reinitialized. This provides some degree of isolation of the tests even when they're reusing the same JVM. By contrast, calling the two different methods from within the same test exposes the second one to initializations left from the first one. In addition (though I'm not too concerned about this) if the first test fails the second won't be run at all. Merging these tests is kind of out of scope for this particular bug, and since I wasn't fully able to convince myself that the merged tests have the same semantics as the unmerged tests, I'd prefer not to see the merging of these tests as part of this changeset. (Some cleanup of these two tests is probably warranted eventually. I'd take a different approach of merging and refactoring the sources but keeping them as separate test runs, using two @run tags. But we should work on that separately. Meanwhile, the overhead of having these as separate tests is minimal, especially if they're not run in /othervm mode.) I don't think the removal of java/rmi/Naming from exclusiveAccess.dirs is safe at this point. The DefaultRegistryPort.java test uses the default registry port, not a unique one. Conceptually it would need to be converted to use the TestLibrary unique port stuff, but the test is actually about using the default port. So, the solution here isn't obvious. In addition, the java/rmi/Naming/legalRegistryNames/LegalRegistryNames.java test also uses the default registry port. It too will need to converted before java/rmi/Naming is removed from exclusiveAccess.dirs. The java/rmi/Naming/LookupIPv6.java test was converted to use the TestLibrary unique port technique, but only partially. The registry is created on the unique port, but the Naming.lookup() call on the last line of the test doesn't provide a port number, so it does the lookup on the default port instead. This will cause the test to fail in almost all cases. I have to ask, did you run this test with your modifications? (Well, the test would pass if IPv6 is not enabled on the machine running the test, but it only passes because the part of the test that creates and uses the registry is bypassed entirely if IPv6 is not enabled. If you're modifying code, you need to take responsibility for ensuring that the code being modified is actually being run and is doing what you expect.) LookupIPv6.java also needs to have these lines added to the test tags: * @bug 4402708 + * @library ../testlibrary + * @build TestLibrary * @run main/othervm -Djava.net.preferIPv6Addresses=true LookupIPv6 (Their absence will cause the test also to fail in a clean build, but the test will find a TestLibrary class if one had been compiled by a previous test that had required it.) Maybe we should separate the othervm changes (removal of the rmi dirs from othervm.dirs, and addition of /othervm) from the exclusiveAccess.dirs changes. A separate bug would be filed for exclusiveAccess.dirs. I know this means the bug count won't go down, but dealing with exclusiveAccess.dirs means that the logic of various tests will need to be change to use the unique port mechanism. This is a fair chunk of work and it's logically distinct from the
