On 2/11/2011 3:27 PM, Iris Clark wrote:
Hi, Mark.
You gave me a copy of those test when I was working on this bug:
4463011: (bf) View-buffer bulk get/put operations are slow
If I recall correctly, I modified the tests for my particular problem
and added them to that bug as attachments.
Thank
Hi core-libs-dev,
In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from line
626, I found that the scope of "#ifdef __solaris__" might be too narrow,
since it also works for some kind of OS which I'm currently working on,
such as AIX.
So I suggest to just remove the '#ifdef __solari
On 11/02/2011 04:56 PM, Jonathan Lu wrote:
Hi core-libs-dev,
In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from line
626, I found that the scope of "#ifdef __solaris__" might be too
narrow, since it also works for some kind of OS which I'm currently
working on, such as AIX.
So I
On 02/11/2011 06:35, Alan Bateman wrote:
On 01/11/2011 09:47, Seán Coffey wrote:
:
Are you referring to the parent.close() call ? If otherParents is
null, then we only have one reference to this FileDesriptor - i.e the
Stream that has called close().
It's parent.close() that I'm wondering a
On 02/11/2011 09:18, Seán Coffey wrote:
The parent gets added to the ArrayList when that ArrayList needs to be
set up (more than 1 referent) so this shouldn't be a problem. When the
ArrayList (otherParents) is non-null a close will be called on the
stream that initiated the close operation (t
On 01/11/2011 23:54, David Holmes wrote:
This fix seems inconsistent with how this non-String problem is
handled elsewhere.
It is, but (for whatever reason) is specified to return "the previous
string value of the system property" whereas Properties.getProperty is
specified to return "the va
On 2/11/2011 7:01 PM, Jonathan Lu wrote:
On 11/02/2011 04:56 PM, Jonathan Lu wrote:
Hi core-libs-dev,
In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from line
626, I found that the scope of "#ifdef __solaris__" might be too
narrow, since it also works for some kind of OS which I'm
On 11/02/2011 07:00 PM, David Holmes wrote:
On 2/11/2011 7:01 PM, Jonathan Lu wrote:
On 11/02/2011 04:56 PM, Jonathan Lu wrote:
Hi core-libs-dev,
In jdk/src/solaris/native/java/util/TimeZone_md.c, starting from line
626, I found that the scope of "#ifdef __solaris__" might be too
narrow, since
http://cr.openjdk.java.net/~weijun/7107522/webrev.00/
We must stay with the fact that a build number cannot exceed 255 while
the system property "java.runtime.version" might show a bigger one. This
fix only makes sure the test always passes.
If you think there should be a more proper mail lis
On 02/11/2011 11:46, Weijun Wang wrote:
http://cr.openjdk.java.net/~weijun/7107522/webrev.00/
We must stay with the fact that a build number cannot exceed 255 while
the system property "java.runtime.version" might show a bigger one.
This fix only makes sure the test always passes.
Max - I don'
Hi Jonathan,
IIRC, the difference came from some behavioral difference between the
Linux and Solaris libc date-time functions and/or the date command, and
TimeZone_md.c tries to follow the difference. But the code was written
long ago. The difference may no longer exist.
Thanks,
Masayosh
Hi Max,
There is a bit of history here and I believe the right fix should be to
fix the JDK_GetVersionInfo0 function in
src/share/native/common/jdk_util.c to work with a large build number but
treats any build number > 255 is an internal build.
This test is intended to test the native inter
Hi Alan,
On 2/11/2011 7:47 PM, Alan Bateman wrote:
On 01/11/2011 23:54, David Holmes wrote:
This fix seems inconsistent with how this non-String problem is
handled elsewhere.
It is, but (for whatever reason) is specified to return "the previous
string value of the system property" whereas Pro
On 10/31/2011 5:11 PM, Mike Skells wrote:
(2) Iti is true that this is not a performance gain by code
improvement, but it is a performnce gain by specification.
The same arguement applies to allowing a Zip Compression of 1 rather
than the default. As for the spec, all I have seen is that it
Updated webrev:
http://cr.openjdk.java.net/~weijun/7107522/webrev.01/
-Max
On 11/03/2011 02:01 AM, Mandy Chung wrote:
Hi Max,
There is a bit of history here and I believe the right fix should be to
fix the JDK_GetVersionInfo0 function in
src/share/native/common/jdk_util.c to work with a la
15 matches
Mail list logo