hg: jdk7/tl/jdk: 2 new changesets
Changeset: d133d4052378 Author:ohair Date: 2009-07-08 09:11 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d133d4052378 6858127: Missing -DNDEBUG on Linux and Windows native code compiles Reviewed-by: tbell, dcubed ! make/common/Defs-linux.gmk ! make/common/Defs-windows.gmk Changeset: d3a08f8c3c86 Author:ohair Date: 2009-07-08 09:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d3a08f8c3c86 681: java -Xrunhprof crashes when running with classes compiled with targed=7 Reviewed-by: tbell, dcubed ! src/share/demo/jvmti/java_crw_demo/java_crw_demo.c ! test/demo/jvmti/hprof/HelloWorld.java ! test/demo/jvmti/hprof/StackMapTableTest.java
Re: malloc failures in java/util/zip/Deflater
Il 08/07/2009 20:52, Roman Kennke ha scritto: Hi Mario, According to the specs, malloc may return either a valid pointer that can be passed to free, or NULL, while generally NULL is considered to be a failure. Linux and Solaris, albeit non specifying it, return always a valid pointer, as far as I know I think NULL is returned in an out of memory situation, which is very rare on modern OSes, but I think it's still possible. The right thing to do here is check for NULL and (try to) throw an OOME. Which is what is beeing done already (AFAICS). What are you trying to solve by additionally checking for len 0? /Roman Hi Roman, The OutOfMemory is thrown correctly in case of failure (it wasn't up to some builds ago, though :). The problem is when passing a 0 length argument to malloc (from the man page): malloc() allocates size bytes and returns a pointer to the allocated memory. The memory is not cleared. If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free(). Linux and Solaris AFAIK return a pointer to valid memory, but this is not specified, and the code only checks for NULL as in failure. So it may be the case that this changes in future. In my case I have a not-so-modern OS that returns NULL in such case. So, to decide if we have a memory error or not, we need the additional len 0 check. Cheers, Mario
Re: malloc failures in java/util/zip/Deflater
Hi Mario, According to the specs, malloc may return either a valid pointer that can be passed to free, or NULL, while generally NULL is considered to be a failure. Linux and Solaris, albeit non specifying it, return always a valid pointer, as far as I know I think NULL is returned in an out of memory situation, which is very rare on modern OSes, but I think it's still possible. The right thing to do here is check for NULL and (try to) throw an OOME. Which is what is beeing done already (AFAICS). What are you trying to solve by additionally checking for len 0? /Roman Hi Roman, The OutOfMemory is thrown correctly in case of failure (it wasn't up to some builds ago, though :). The problem is when passing a 0 length argument to malloc (from the man page): malloc() allocates size bytes and returns a pointer to the allocated memory. The memory is not cleared. If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free(). Linux and Solaris AFAIK return a pointer to valid memory, but this is not specified, and the code only checks for NULL as in failure. So it may be the case that this changes in future. In my case I have a not-so-modern OS that returns NULL in such case. So, to decide if we have a memory error or not, we need the additional len 0 check. Ah, I see! The len==0 case is not a failure, but some OSes return NULL anyway, running into an OOME even when there's no error? Now that you don't throw OOME in these cases, you might want to check the pointer later so that you don't get a segfault when you pass this NULL pointer to other functions like free(). (uhm .. TARGET_FREE_UNSAFE? oops, internal joke... ;-). ) /Roman
LinkedBlockingDeque and LinkedBlockingQueue
Doug Lea and I have been working (slowly) on fixing LinkedBlockingDeque and LinkedBlockingQueue Although changes are unfinished, there has been great recent interest in this http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6805775 LinkedBlockingQueue Nodes should unlink themselves before becoming garbage and so I am publishing them now. As often happens, the intended one-line change has proved insufficient and has ballooned into many hours of work. http://cr.openjdk.java.net/~martin/webrevs/openjdk7/BlockingQueue/ Martin
Re: malloc failures in java/util/zip/Deflater
Hi Mario, I'm not familiar with this particular code but doesn't a value of this_len==0 imply that there's nothing to do and a whole chunk of code here can be skipped? Is finding this_len==0 even valid here? Your patch fixes your problem, but it seems to me the code either shouldn't get this_len==0 or else should be handling it differently. Cheers, David Holmes Mario Torre said the following on 07/09/09 03:59: Hi all, I've found a problem in the Deflater code in OpenJDK, where a length of zero bytes is passed to malloc. According to the specs, malloc may return either a valid pointer that can be passed to free, or NULL, while generally NULL is considered to be a failure. Linux and Solaris, albeit non specifying it, return always a valid pointer, as far as I know, but I have a weird OS here that does indeed return NULL. I've fixed this issue locally, and thought I could share the patch with you: http://cr.openjdk.java.net/~neugens/deflater/webrev.00/ Cheers, Mario
Code review request for 6628737: Specification of wrapper class valueOf static factories should require caching
Hello.
Since JDK 5, to implement autoboxing, javac has relied on various static
factory methods in the wrapper classes to perform the caching in the
required range. While the factories said they could cache, they did not
state they would definitely cache in the required range given in JLSv3
section 5.1.7:
http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7
Please review the patch below of my specification changes to mandate the
caching. The Boolean factory already mandates caching. (For those
interested in such things, tn parallel a ccc request has been filed to
track the specification change.)
-Joe
--- old/src/share/classes/java/lang/Byte.java2009-07-08
18:38:11.0 -0700
+++ new/src/share/classes/java/lang/Byte.java2009-07-08
18:38:11.0 -0700
@@ -90,8 +90,8 @@
* If a new {...@code Byte} instance is not required, this method
* should generally be used in preference to the constructor
* {...@link #Byte(byte)}, as this method is likely to yield
- * significantly better space and time performance by caching
- * frequently requested values.
+ * significantly better space and time performance since
+ * all byte values are cached.
*
* @param b a byte value.
* @return a {...@code Byte} instance representing {...@code b}.
--- old/src/share/classes/java/lang/Character.java2009-07-08
18:38:13.0 -0700
+++ new/src/share/classes/java/lang/Character.java2009-07-08
18:38:13.0 -0700
@@ -2571,6 +2571,10 @@
* significantly better space and time performance by caching
* frequently requested values.
*
+ * This method will always cache values in the range '#92;u'
+ * to '#92;u007f', inclusive, and may cache other values outside
+ * of this range.
+ *
* @param c a char value.
* @return a ttCharacter/tt instance representing ttc/tt.
* @since 1.5
--- old/src/share/classes/java/lang/Integer.java2009-07-08
18:38:14.0 -0700
+++ new/src/share/classes/java/lang/Integer.java2009-07-08
18:38:14.0 -0700
@@ -638,6 +638,9 @@
* to yield significantly better space and time performance by
* caching frequently requested values.
*
+ * This method will always cache values in the range -128 to 127,
+ * inclusive, and may cache other values outside of this range.
+ *
* @param i an {...@code int} value.
* @return an {...@code Integer} instance representing {...@code i}.
* @since 1.5
--- old/src/share/classes/java/lang/Long.java2009-07-08
18:38:16.0 -0700
+++ new/src/share/classes/java/lang/Long.java2009-07-08
18:38:16.0 -0700
@@ -560,6 +560,11 @@
* significantly better space and time performance by caching
* frequently requested values.
*
+ * Note that unlike the {...@linkplain Integer#valueOf(int)
+ * corresponding method} in the {...@code Integer} class, this method
+ * is emnot/em required to cache values within a particular
+ * range.
+ *
* @param l a long value.
* @return a {...@code Long} instance representing {...@code l}.
* @since 1.5
--- old/src/share/classes/java/lang/Short.java2009-07-08
18:38:17.0 -0700
+++ new/src/share/classes/java/lang/Short.java2009-07-08
18:38:17.0 -0700
@@ -219,6 +219,9 @@
* significantly better space and time performance by caching
* frequently requested values.
*
+ * This method will always cache values in the range -128 to 127,
+ * inclusive, and may cache other values outside of this range.
+ *
* @param s a short value.
* @return a {...@code Short} instance representing {...@code s}.
* @since 1.5
Re: Code review request for 6628737: Specification of wrapper class valueOf static factories should require caching
Looks fine to me. Minor formatting nit in each delta except the first: ... --- old/src/share/classes/java/lang/Character.java2009-07-08 18:38:13.0 -0700 +++ new/src/share/classes/java/lang/Character.java2009-07-08 18:38:13.0 -0700 @@ -2571,6 +2571,10 @@ * significantly better space and time performance by caching * frequently requested values. * + * This method will always cache values in the range '#92;u' + * to '#92;u007f', inclusive, and may cache other values outside + * of this range. + * * @param c a char value. * @return a ttCharacter/tt instance representing ttc/tt. * @since 1.5 I'm guessing, from the blank lines around this paragraph, that you want it to be displayed as a separate paragraph. If that's the case then you need to wrap it in p ... /p. - Mark
