Codereview request 7156873: (zipfs) FileSystems.newFileSystem(uri, env) fails for uri with escaped octets

[Xueming Shen]

Hi

Please help review the fix for 7156873.  It appears 
URI.getRawSchemeSpecificPart() is the more appropriate
method to use to obtain the "scheme", which returns the scheme in its 
"quoted" form.


http://cr.openjdk.java.net/~sherman/7156873/webrev

Thanks,
-Sherman

Re: Replace the static error string in ZIP_Put_In_Cache0 with on stack memory

[Sean Chou]

Hi Alan,

Many thanks.

I updated the patch, ZIP_Open frees the error message and set "Zip file
open error".

The new webrev is :  http://cr.openjdk.java.net/~zhouyx/7159982/webrev.01/

Please take a look once more.

On Thu, Apr 12, 2012 at 4:09 AM, Alan Bateman wrote:

> On 11/04/2012 15:58, Sean Chou wrote:
>
>> Hi hotspot guys,
>>
>>Would any one like to take a look at this? I'm trying to fix a
>> potential race in ZIP_Open, it is found classLoader.cpp uses this function.
>> So a webrev for hotspot is made as well, but I need a sponsor from hotspot
>> as suggested by Alan Bateman.
>>
>>The start of this thread is http://mail.openjdk.java.net/**
>> pipermail/core-libs-dev/2012-**April/009766.html.
>>The webrevs: http://cr.openjdk.java.net/~**
>> zhouyx/7159982/webrev-hotspot.**00/<
>> http://cr.openjdk.java.net/%**7Ezhouyx/7159982/webrev-**hotspot.00/
>> >
>> and 
>> http://cr.openjdk.java.net/~**zhouyx/7159982/webrev.00/<
>> http://cr.openjdk.java.net/%**7Ezhouyx/7159982/webrev.00/>
>>  .
>>
>>
>>And, I found JDK_Version::is_gte_jdk18x_**version suggested by Alan
>> does not exist in hotspot yet, shall I add it to the patch too ?
>>
> I had a brief chat with Coleen Phillimore about this. One suggestion that
> would avoid HotSpot changes is to change ZIP_Open so that it doesn't return
> an error message or returns something fixed. It's not used in the VM anyway
> (as per Coleen's reply). We need the error message for the java.util.zip
> APIs but that doesn't go through ZIP_Open so it means it can be freed and
> *pmsg = NULL returned (or a pointer to one fixed generic message).
>
> -Alan
>



-- 
Best Regards,
Sean Chou

Codereview request for 7152690: Initialization error with charset SJIS_0213 when security manager is enabled

[Xueming Shen]

Hi

Please help codereview the change for #7152690

http://cr.openjdk.java.net/~sherman/7152690/webrev

This is an overlook when we changed SJIS_0213 implementation in 7. The 
"resource reading"

obviously needs to be wrapped in doPrivileged block.

Thanks!
-Sherman

Re: Integer.parseInt

[Joe Darcy]

On 4/11/2012 7:45 AM, Rémi Forax wrote:

On 04/11/2012 04:18 PM, Benedict Elliott Smith wrote:

Hi,

Looking at the source code, it doesn't appear as though there is any 
reason
to require the input be a String - only length() and charAt() are 
called,
which are both declared by CharSequence. Is there a reason I can't 
fathom,

or was it an oversight? It would be nice to widen the type for this (and
potentially other equivalent methods).


Integer.parseInt (1.0 or 1.1) pre-date CharSequence (1.4),
that's why it use a String an not a CharSequence.

If you don't want to break all already compiled programs,
you can't just replace String by CharSequence because the exact 
signature of the method

(with the parameter types) is encoded in the bytecode.
Joe Darcy write a cool blog post on that [1].


That is a kinder description of the blog post than I would expect :-)

FYI, a fuller exploration of that issue in a broader context is written 
up in:



http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html




The best here is to add new methods that takes a CharSequence, move 
the code that use
a String in them and change the method that takes a String to delegate 
to the one that use

a CharSequence.

cheers,
Rémi
[1] https://blogs.oracle.com/darcy/entry/kinds_of_compatibility



Remi and I have in the past had differences of opinion on the utility of 
introducing CharSequence versions of such methods.


One benefit to using a string is that the object is immutable; there are 
no time-of-check-versus-time-of-use conditions to worry about.  Robust 
code should arguably work sensibly even with mutable CharSequences, and 
the easiest way to ensure that is to call the toString method of a 
CharSequence passed as a parameter.


-Joe

Re: sun.management.Agent: the properties.putAll API may fail with ConcurrentModifcationException on multi-thread scenario

[Mandy Chung]

On 4/11/2012 12:36 AM, Deven You wrote:

Hi core-libs-devs,

I am not sure if sun.management.Agent belongs to jmx-dev mailing list, 
if so please anyone tell me.




serviceability-dev (cc'ed) is the mailing list for this patch.

This issue is that the sun.management.Agent.loadManagementProperties() 
will invoke properties.putAll which will throw 
ConcurrentModifcationException if there are other threads which modify 
the properties concurrently.


I have made a patch[1] which synchronize the sysProps so that putAll 
can work on multi-thread scenario. The test case is also available in 
[1].




I think this could still run into CME.  System Properties is not a 
synchronized map and the setter methods (System.setProperty or 
Properties.put method) doesn't synchronize on the Properties object.


Mandy


Thanks a lot!

[1] http://cr.openjdk.java.net/~littlee/OJDK-256/webrev.00 

hg: jdk8/tl/jdk: 7157903: JSSE client sockets are very slow

[bradford . wetmore]

Changeset: 10480cf00dcd
Author:wetmore
Date:  2012-04-11 17:12 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/10480cf00dcd

7157903: JSSE client sockets are very slow
Reviewed-by: xuelei

! src/share/classes/sun/security/ssl/AppOutputStream.java
! src/share/classes/sun/security/ssl/EngineOutputRecord.java
! src/share/classes/sun/security/ssl/OutputRecord.java
! src/share/classes/sun/security/ssl/SSLSocketImpl.java

review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

[Rob McKenna]

Hi folks,

I'm hoping for some feedback on the above. Webrev:

http://cr.openjdk.java.net/~robm/4244896/webrev.00/

This bug adds two abstract methods to Process.java with the intention of:

1) providing a facility to implement a destroyForcibly method. In 
practical terms this means provide a method that will send a SIGKILL to 
the subprocess in *nix environments as opposed to the SIGTERM that is 
currently being sent. (Windows' destroy() method effectively behaves 
like this already)


2) providing a facility to check whether the subprocess is still alive.

As per the bug report the toString/pid work has been left to be 
completed separately.


Notes:

a) It has been pointed out to me that the addition of abstract methods 
to java.lang.Process should be discussed, particularly as to whether 
default methods should be provided.


b) In src/windows/native/java/lang/ProcessImpl_md.c I chose to use 
WaitForSingleObject on the off chance that a process may choose to 
return STILL_ACTIVE as an error code.


Thanks!

-Rob

Re: RFR 7116200: (cs) test/java/nio/charset/coders/StreamTimeout.java fails with "Address already in use"

[Rémi Forax]

On 04/11/2012 10:02 PM, Alan Bateman wrote:

On 11/04/2012 19:06, Jim Gish wrote:

Hi,

Please review the following

Description:

The current code uses the fixed port of 2 and the test fails if 
that port is in use.  The patch creates the socket on any open port 
using new ServerSocket(0) and then determines the port in use with 
getLocalPort() on the socket.  That port is then used when creating 
the client.  This ensures the test won't fail with "address already 
in use".


Also, all sockets are closed when done. (Would appreciate comments on 
whether I have engaged in overkill here, or not.)


Patch:

http://cr.openjdk.java.net/~jgish/7116200/webrev.00/

Tests run: jdk_nio3 -- all pass.

Thanks,
   Jim Gish
I agree with Rémi, it would be better for Client to have a final field 
for the port or the client Socket and have it passed to the 
constructor. It would also be nice if Client implemented Closeable.


One other thing is that try-with-resources with clean-up the 
closing/exception handling in main. Also I think it would be better 
not to catch the IOException at the end as that would mean the test 
would pass when there is failure.


-Alan.



Following the ideas of Alan, I've also removed the unnecessary code, 
waitABit is not called anymore,
and I've inserted a join to be sure that the thread is finished before 
performing the cleanup.


Rémi


/*
 * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License 
version

 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/* @test
 * @bug 4521942
 * @summary Ensure that InputStreamReaders work properly
 *  when the underlying byte stream times out
 */

import java.io.Closeable;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.InterruptedIOException;
import java.io.OutputStreamWriter;
import java.io.PrintStream;
import java.io.Reader;
import java.io.Writer;
import java.net.ServerSocket;
import java.net.Socket;

public class StreamTimeout {
static final PrintStream log = System.err;
static String charset = "US-ASCII";

private static class Client extends Thread implements Closeable {
private final Socket so;

Client(int port) throws IOException {
so = new Socket("127.0.0.1", port);
}

@Override
public void run() {
try {
Writer wr = new OutputStreamWriter(so.getOutputStream(),
charset);
wr.write("ab");
wr.flush();
} catch (IOException x) {
log.print("Unexpected exception in writer: ");
x.printStackTrace();
System.exit(1);
}
}

@Override
public void close() throws IOException {
so.close();
}
}

private static void gobble(InputStream is, Reader rd,
int ec, boolean force)
throws Exception
{
int a = is.available();
boolean r = rd.ready();
log.print("" + a + " bytes available, "
+ "reader " + (r ? "" : "not ") + "ready");
if (!r && !force) {
log.println();
return;
}
int c;
try {
c = rd.read();
} catch (InterruptedIOException x) {
log.println();
throw x;
}
log.println(", read() ==> "
+ (c >= 0 ? ("'" + (char)c + "'" ): "EOF"));
if (c != ec)
throw new Exception("Incorrect value read: Expected "
+ ec + ", read " + (char)c);
}

public static void main(String[] args) throws Exception {

if (args.length > 0)
charset = args[0];

try(ServerSocket ss = new ServerSocket(0);
Client cl = new Client(ss.getLocalPort())) {

cl.start();

try(Socket s = ss.accept()) {
s.setSoTimeout(150);

try(InputStream is = s.getInputStream();
Reader rd = new Inpu

Re: Code Review Request: 7157893: Warnings Cleanup in java.util.*

[Rémi Forax]

On 04/11/2012 10:06 PM, Mike Duigou wrote:

This thread has gone on long enough I've lost track of the reasoning behind 
some of the choices.

Specifically, I'm wondering why Entry[] is preferred over Entry[] for 
HashMap and Hashtable. Understandably  is needed to the array creation but the 
technique used by WeakHashMap would seem to be equally appropriate for the other hash base Map 
implementations.

Rémi?


WeakHashMap was already warning free so I haven't modified it,
I've just removed one or two raw type warnings.

The main issue with the translation chosen by WeakHashMap is that an 
array of parametrized types
is something that is unsafe (the VM doesn't do a runtime check for the 
array store)
so you can easily add code that you think innocuous but that that will 
introduce a bug.




Mike


Rémi




On Apr 10 2012, at 16:15 , Kurchi Hazra wrote:


Hi Stuart,

   Please find the updated webrev here: 
http://cr.openjdk.java.net/~khazra/7157893/webrev.01/

I hope to have included all the suggestions correctly. Also, note that I made 
some new changes in Hashtable.java at lines 185, 355 and 910 to get rid of some 
additional warnings.

Thanks,
Kurchi


On 4/6/2012 5:35 PM, Stuart Marks wrote:

Hi Kurchi, I think we've converged on the code changes. Please prepare and post 
another webrev for a final cross-check before pushing.

What follows is I think merely residual disagreement over the philosophy of how 
to handle generic casts vs reification. :-)

On 4/6/12 3:06 AM, Rémi Forax wrote:

On 04/05/2012 11:04 PM, Stuart Marks wrote:

I'm somewhat skeptical of making code changes now based on potential future
benefits when/if generics become reified. This was discussed before; see

http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000454.html

In that message, John Rose said "If the best practices have to change, then
we'll have to change that code again. Or maybe the retrofit strategy will
have to take account of the existing code idioms. In any case, we'll cross
that bridge when we get to it. (Coping with reification in this case is a
decision to make tomorrow, not today.)"

I disagree with John. The main issue with generics nowadays is that
most of the people doesn't care about a cast to a type variable because
everybody knows about erasure. So codes are written with an implementation
glitch in mind.
Frankly, I don't know if reification will appear (yes it's a kind of magical)
or not
but I think it's a sloppy path to not consider all casts as equals.

In order to program effectively with generics, I think you have to understand erasure and 
its implications. It may have been an unfortunate choice, but erasure is part of the 
language and we have to deal with it and in some cases rely on it. I don't think it's 
merely an "implementation glitch."

The difficulty I have with reification is that while there are proposals 
floating around for how it could be done, nobody really knows how it will 
eventually turn out, nor whether it will actually be done. If it is eventually 
done, there will legal and illegal constructs, constructs that generate 
warnings, and perhaps a style guide for how to use reified generics properly.

Right now, we can *imagine* what these future rules might be, but it seems 
untenable to me to try to make today's code conform to those imaginary future 
rules, especially in the absence of tools to help support those rules.


If unmaskNull return a V, the code of equals will upcast the value from Object
to V
to just after downcast it from V to Object,
I think it's better that unmask to return Object and upcast it to V when it's
necessary.

Certainly there are cases where there's a redundant downcast and upcast. In a 
reified world, will this be a significant expense? Really, I have no idea.

s'marks

--
-Kurchi

Re: Replace the static error string in ZIP_Put_In_Cache0 with on stack memory

[Alan Bateman]

On 11/04/2012 15:58, Sean Chou wrote:

Hi hotspot guys,

Would any one like to take a look at this? I'm trying to fix a 
potential race in ZIP_Open, it is found classLoader.cpp uses this 
function. So a webrev for hotspot is made as well, but I need a 
sponsor from hotspot as suggested by Alan Bateman.


The start of this thread is 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/009766.html 
.
The webrevs: 
http://cr.openjdk.java.net/~zhouyx/7159982/webrev-hotspot.00/ 

and http://cr.openjdk.java.net/~zhouyx/7159982/webrev.00/ 
  .


And, I found JDK_Version::is_gte_jdk18x_version suggested by Alan 
does not exist in hotspot yet, shall I add it to the patch too ?
I had a brief chat with Coleen Phillimore about this. One suggestion 
that would avoid HotSpot changes is to change ZIP_Open so that it 
doesn't return an error message or returns something fixed. It's not 
used in the VM anyway (as per Coleen's reply). We need the error message 
for the java.util.zip APIs but that doesn't go through ZIP_Open so it 
means it can be freed and *pmsg = NULL returned (or a pointer to one 
fixed generic message).


-Alan

Re: Code Review Request: 7157893: Warnings Cleanup in java.util.*

[Mike Duigou]

This thread has gone on long enough I've lost track of the reasoning behind 
some of the choices.

Specifically, I'm wondering why Entry[] is preferred over Entry[] for 
HashMap and Hashtable. Understandably  is needed to the array creation but 
the technique used by WeakHashMap would seem to be equally appropriate for the 
other hash base Map implementations. 

Rémi?

Mike


On Apr 10 2012, at 16:15 , Kurchi Hazra wrote:

> Hi Stuart,
> 
>   Please find the updated webrev here: 
> http://cr.openjdk.java.net/~khazra/7157893/webrev.01/
> 
> I hope to have included all the suggestions correctly. Also, note that I made 
> some new changes in Hashtable.java at lines 185, 355 and 910 to get rid of 
> some additional warnings.
> 
> Thanks,
> Kurchi
> 
> 
> On 4/6/2012 5:35 PM, Stuart Marks wrote:
>> Hi Kurchi, I think we've converged on the code changes. Please prepare and 
>> post another webrev for a final cross-check before pushing.
>> 
>> What follows is I think merely residual disagreement over the philosophy of 
>> how to handle generic casts vs reification. :-)
>> 
>> On 4/6/12 3:06 AM, Rémi Forax wrote:
>>> On 04/05/2012 11:04 PM, Stuart Marks wrote:
 I'm somewhat skeptical of making code changes now based on potential future
 benefits when/if generics become reified. This was discussed before; see
 
 http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000454.html 
 
 In that message, John Rose said "If the best practices have to change, then
 we'll have to change that code again. Or maybe the retrofit strategy will
 have to take account of the existing code idioms. In any case, we'll cross
 that bridge when we get to it. (Coping with reification in this case is a
 decision to make tomorrow, not today.)"
>>> 
>>> I disagree with John. The main issue with generics nowadays is that
>>> most of the people doesn't care about a cast to a type variable because
>>> everybody knows about erasure. So codes are written with an implementation
>>> glitch in mind.
>>> Frankly, I don't know if reification will appear (yes it's a kind of 
>>> magical)
>>> or not
>>> but I think it's a sloppy path to not consider all casts as equals.
>> 
>> In order to program effectively with generics, I think you have to 
>> understand erasure and its implications. It may have been an unfortunate 
>> choice, but erasure is part of the language and we have to deal with it and 
>> in some cases rely on it. I don't think it's merely an "implementation 
>> glitch."
>> 
>> The difficulty I have with reification is that while there are proposals 
>> floating around for how it could be done, nobody really knows how it will 
>> eventually turn out, nor whether it will actually be done. If it is 
>> eventually done, there will legal and illegal constructs, constructs that 
>> generate warnings, and perhaps a style guide for how to use reified generics 
>> properly.
>> 
>> Right now, we can *imagine* what these future rules might be, but it seems 
>> untenable to me to try to make today's code conform to those imaginary 
>> future rules, especially in the absence of tools to help support those rules.
>> 
>>> If unmaskNull return a V, the code of equals will upcast the value from 
>>> Object
>>> to V
>>> to just after downcast it from V to Object,
>>> I think it's better that unmask to return Object and upcast it to V when 
>>> it's
>>> necessary.
>> 
>> Certainly there are cases where there's a redundant downcast and upcast. In 
>> a reified world, will this be a significant expense? Really, I have no idea.
>> 
>> s'marks
> 
> -- 
> -Kurchi
> 

Re: RFR 7116200: (cs) test/java/nio/charset/coders/StreamTimeout.java fails with "Address already in use"

[Alan Bateman]

On 11/04/2012 19:06, Jim Gish wrote:

Hi,

Please review the following

Description:

The current code uses the fixed port of 2 and the test fails if 
that port is in use.  The patch creates the socket on any open port 
using new ServerSocket(0) and then determines the port in use with 
getLocalPort() on the socket.  That port is then used when creating 
the client.  This ensures the test won't fail with "address already in 
use".


Also, all sockets are closed when done. (Would appreciate comments on 
whether I have engaged in overkill here, or not.)


Patch:

http://cr.openjdk.java.net/~jgish/7116200/webrev.00/

Tests run: jdk_nio3 -- all pass.

Thanks,
   Jim Gish
I agree with Rémi, it would be better for Client to have a final field 
for the port or the client Socket and have it passed to the constructor. 
It would also be nice if Client implemented Closeable.


One other thing is that try-with-resources with clean-up the 
closing/exception handling in main. Also I think it would be better not 
to catch the IOException at the end as that would mean the test would 
pass when there is failure.


-Alan.

Re: RFR 7116200: (cs) test/java/nio/charset/coders/StreamTimeout.java fails with "Address already in use"

[Rémi Forax]

On 04/11/2012 08:06 PM, Jim Gish wrote:

Hi,

Please review the following

Description:

The current code uses the fixed port of 2 and the test fails if 
that port is in use.  The patch creates the socket on any open port 
using new ServerSocket(0) and then determines the port in use with 
getLocalPort() on the socket.  That port is then used when creating 
the client.  This ensures the test won't fail with "address already in 
use".


Also, all sockets are closed when done. (Would appreciate comments on 
whether I have engaged in overkill here, or not.)


Patch:

http://cr.openjdk.java.net/~jgish/7116200/webrev.00/

Tests run: jdk_nio3 -- all pass.

Thanks,
   Jim Gish


ah,
there is no guarantee from the memory model that the main thread will 
see the field 'so' initialized

even if the thread client has executed the method run().
And there is a kind of  a race between the main thread and the thread 
Client,
the main thread calls closeSocket() while the method run() may have not 
finished.
It's not a clear race because the socket IOs are used as a kind of 
synchro but

it's really hairy.

Rémi

RFR 7116200: (cs) test/java/nio/charset/coders/StreamTimeout.java fails with "Address already in use"

[Jim Gish]

Hi,

Please review the following

Description:

The current code uses the fixed port of 2 and the test fails if that 
port is in use.  The patch creates the socket on any open port using new 
ServerSocket(0) and then determines the port in use with getLocalPort() 
on the socket.  That port is then used when creating the client.  This 
ensures the test won't fail with "address already in use".


Also, all sockets are closed when done. (Would appreciate comments on 
whether I have engaged in overkill here, or not.)


Patch:

http://cr.openjdk.java.net/~jgish/7116200/webrev.00/

Tests run: jdk_nio3 -- all pass.

Thanks,
   Jim Gish

Re: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values

[Dmitry Samersoff]

Looks good for me.

-Dmitry

On 2012-04-11 20:24, Staffan Larsen wrote:

Apparently something went wrong with the webrev. Here is new one:

http://cr.openjdk.java.net/~sla/7147848/webrev.02/

Thanks Dmitry,
/Staffan

On 11 apr 2012, at 12:33, Dmitry Samersoff wrote:


Staffan,

MacosxOperatingSystem.c

Probably something went wrong with webrev:

48 if (kr != KERN_SUCCESS) {
49 return 0;
50 }


133 if (gettimeofday(&now, NULL)) {
134 return -1;
135 }

-Dmitry


On 2012-04-11 11:52, Staffan Larsen wrote:

Thank you all for your comments!

New webrev here: http://cr.openjdk.java.net/~sla/7147848/webrev.01/

Changes:
- Fixed Dmitry's comments
- Updated TestTotalSwap.sh for Darwin (thanks Mandy)

I have verified the values manually by running a Java program (see
attachment) and comparing to top and other system utilities. I've also
compared output with a Linux system to compare magnitude of numbers. I
have run the various regression tests.

Thanks,
/Staffan




On 10 apr 2012, at 21:57, Mandy Chung wrote:


Staffan, Roger,

There isn't any undocumented semantics other than what the
specification for com.sun.management.OperatingSystemMXBean specifies
(that is indicated by its method name):
http://docs.oracle.com/javase/7/docs/jre/api/management/extension/index.html

As Roger suggests, you can do some sanity tests and compare the result
with native commands (top or other CLI). There are a few regression
tests in jdk/test/com/sun/management. In particular, you might want to
update test/com/sun/management/TestTotalSwap.sh to check the swap
space with a suitable macosx command, if there is one.

FYI. I'm not familiar with Mac OS X API and didn't review the code.

Mandy

On 4/10/2012 10:51 AM, rhoover wrote:

Scott, Steffan

(I am he one who put in the original lines of: return -1.0; // not
available being replaced by this patch)

I was reluctant to implement these functions because the linux code
was quite involved and it appeared to me that there might be some
additional semantics to what was implemented than what was indicated
by the function names alone.

I have not compared the code with the 'top' source, but it looks
plausible. As a sanity test, the function values being returned could
be printed by a java program and visually compared with the output of
'top' as a system is loaded up. It might also be wise to run the same
java program on other platforms to make sure that the magnitude of
the numbers is in the same ballpark.

On Apr 10, 2012, at 10:21 AM, Scott Kovatch wrote:


Regarding Apple, Roger Hoover would be a good person to look at
this, as he's spent more time in the Darwin levels of the VM. I
think he's still partially attached to the OpenJDK work.

-- Scott

On Apr 10, 2012, at 8:58 AM, Daniel D. Daugherty wrote:


Staffan,

I reviewed it and I think it looks OK. I tried looking at the code
in MacosxOperatingSystem.c relative to the Linux version, but I think
it is easily possible to miss something subtle here.

You might try a direct ping to Mandy Chung since M&M was her area.
You might also try a direct ping to Mike Swingler to get an Apple
reviewer.

Dan



On 4/10/12 3:30 AM, Staffan Larsen wrote:

Any takers for this review? (added core-libs-dev as well)

Thanks,
/Staffan

On 3 apr 2012, at 15:39, Staffan Larsen wrote:


Please review the following fix:

webrev:
http://cr.openjdk.java.net/~sla/7147848/webrev.00/
>
>
>>
bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848

This fix implements the missing functionality in
UnixOperatingSystem for Mac OS X. Any feedback on the
implementation is welcome as I am not very familiar with the APIs
in Mac OS X.

I have verified that the changes build on all platforms through
JPRT. The correctness has been verified manually by looking in
JConsole and running the tests in
test/java/lang/management/OperatingSystemMXBean
test/com/sun/management/OperatingSystemMXBean.

Thanks,
/Staffan





--
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...





--
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...

Re: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values

[Staffan Larsen]

Apparently something went wrong with the webrev. Here is new one:

http://cr.openjdk.java.net/~sla/7147848/webrev.02/

Thanks Dmitry,
/Staffan

On 11 apr 2012, at 12:33, Dmitry Samersoff wrote:

> Staffan,
> 
> MacosxOperatingSystem.c
> 
> Probably something went wrong with webrev:
> 
> 48 if (kr != KERN_SUCCESS) {
> 49 return 0;
> 50 }
> 
> 
> 133 if (gettimeofday(&now, NULL)) {
> 134return -1;
> 135 }
> 
> -Dmitry
> 
> 
> On 2012-04-11 11:52, Staffan Larsen wrote:
>> Thank you all for your comments!
>> 
>> New webrev here: http://cr.openjdk.java.net/~sla/7147848/webrev.01/
>> 
>> Changes:
>> - Fixed Dmitry's comments
>> - Updated TestTotalSwap.sh for Darwin (thanks Mandy)
>> 
>> I have verified the values manually by running a Java program (see
>> attachment) and comparing to top and other system utilities. I've also
>> compared output with a Linux system to compare magnitude of numbers. I
>> have run the various regression tests.
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>> 
>> 
>> On 10 apr 2012, at 21:57, Mandy Chung wrote:
>> 
>>> Staffan, Roger,
>>> 
>>> There isn't any undocumented semantics other than what the
>>> specification for com.sun.management.OperatingSystemMXBean specifies
>>> (that is indicated by its method name):
>>> http://docs.oracle.com/javase/7/docs/jre/api/management/extension/index.html
>>> 
>>> As Roger suggests, you can do some sanity tests and compare the result
>>> with native commands (top or other CLI). There are a few regression
>>> tests in jdk/test/com/sun/management. In particular, you might want to
>>> update test/com/sun/management/TestTotalSwap.sh to check the swap
>>> space with a suitable macosx command, if there is one.
>>> 
>>> FYI. I'm not familiar with Mac OS X API and didn't review the code.
>>> 
>>> Mandy
>>> 
>>> On 4/10/2012 10:51 AM, rhoover wrote:
 Scott, Steffan
 
 (I am he one who put in the original lines of: return -1.0; // not
 available being replaced by this patch)
 
 I was reluctant to implement these functions because the linux code
 was quite involved and it appeared to me that there might be some
 additional semantics to what was implemented than what was indicated
 by the function names alone.
 
 I have not compared the code with the 'top' source, but it looks
 plausible. As a sanity test, the function values being returned could
 be printed by a java program and visually compared with the output of
 'top' as a system is loaded up. It might also be wise to run the same
 java program on other platforms to make sure that the magnitude of
 the numbers is in the same ballpark.
 
 On Apr 10, 2012, at 10:21 AM, Scott Kovatch wrote:
 
> Regarding Apple, Roger Hoover would be a good person to look at
> this, as he's spent more time in the Darwin levels of the VM. I
> think he's still partially attached to the OpenJDK work.
> 
> -- Scott
> 
> On Apr 10, 2012, at 8:58 AM, Daniel D. Daugherty wrote:
> 
>> Staffan,
>> 
>> I reviewed it and I think it looks OK. I tried looking at the code
>> in MacosxOperatingSystem.c relative to the Linux version, but I think
>> it is easily possible to miss something subtle here.
>> 
>> You might try a direct ping to Mandy Chung since M&M was her area.
>> You might also try a direct ping to Mike Swingler to get an Apple
>> reviewer.
>> 
>> Dan
>> 
>> 
>> 
>> On 4/10/12 3:30 AM, Staffan Larsen wrote:
>>> Any takers for this review? (added core-libs-dev as well)
>>> 
>>> Thanks,
>>> /Staffan
>>> 
>>> On 3 apr 2012, at 15:39, Staffan Larsen wrote:
>>> 
 Please review the following fix:
 
 webrev:
 http://cr.openjdk.java.net/~sla/7147848/webrev.00/
 >
 bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848
 
 This fix implements the missing functionality in
 UnixOperatingSystem for Mac OS X. Any feedback on the
 implementation is welcome as I am not very familiar with the APIs
 in Mac OS X.
 
 I have verified that the changes build on all platforms through
 JPRT. The correctness has been verified manually by looking in
 JConsole and running the tests in
 test/java/lang/management/OperatingSystemMXBean
 test/com/sun/management/OperatingSystemMXBean.
 
 Thanks,
 /Staffan
>> 
> 
> 
> -- 
> Dmitry Samersoff
> Java Hotspot development team, SPB04
> * There will come soft rains ...

Re: Replace the static error string in ZIP_Put_In_Cache0 with on stack memory

[Sean Chou]

Hi hotspot guys,

Would any one like to take a look at this? I'm trying to fix a
potential race in ZIP_Open, it is found classLoader.cpp uses this function.
So a webrev for hotspot is made as well, but I need a sponsor from hotspot
as suggested by Alan Bateman.

The start of this thread is
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/009766.html.
The webrevs:
http://cr.openjdk.java.net/~zhouyx/7159982/webrev-hotspot.00/
and  http://cr.openjdk.java.net/~zhouyx/7159982/webrev.00/  .

And, I found JDK_Version::is_gte_jdk18x_version suggested by Alan does
not exist in hotspot yet, shall I add it to the patch too ?

On Tue, Apr 10, 2012 at 4:10 PM, Alan Bateman wrote:

> On 10/04/2012 08:10, Sean Chou wrote:
>
>>
>>And it is found that hotspot calls ZIP_Open through (*ZipOpen) in file
>> classLoader.cpp .So I also made a patch for it and add hotspot-dev to cc
>> list.
>>File classLoader.cpp is the only one I have found calling ZIP_Open.
>>
>> The webrev for hotspot is:
>> http://cr.openjdk.java.net/~**zhouyx/7159982/webrev-hotspot.**00/<
>> http://cr.openjdk.java.net/%**7Ezhouyx/7159982/webrev-**hotspot.00/
>> >
>>
>>
>>
>> To hotspot guys,
>>
>>We are trying to make the error path in ZIP_Open in
>> src/share/native/java/util/**zip/zip_util.c thread safe by changing the
>> errbuf[] from static array to on stack array. This will cause the returned
>> error string allocated from heap, which need to be freed. I checked the
>> code and found only classLoader.cpp calls this function, so I made the
>> above webrev. Please take a look.
>>
>>  It's good that you spotted that this is called from the VM (I'd
> forgotten that). In that case things get a bit more complicated because the
> hotspot repository takes a different route into master and also goes into
> 7u releases too. I'll leave the HotSpot group to comment on your proposed
> change but I assume it will require adding 
> JDK_Version::is_gte_jdk18x_**version
> so that the JDK version can be tested before decided whether to free the
> error message. It will also require a sponsor as you cannot push changes to
> jdk8/tl/hotspot, all HotSpot changes require going through a build+test
> system (no direct pushes).
>
> -Alan
>



-- 
Best Regards,
Sean Chou

Re: New reviewers: 7160496 : Rename JDK8 JAXP source directory

[Kelly O'Hair]

Looks fine to me.

-kto

On Apr 10, 2012, at 8:39 PM, Joe Wang wrote:

> After removing the jaxp source drop bundle process, refer to 7150324, the 
> source structure needs to be changed to be consistent with that of jdk7. I 
> will rename jdk8/jaxp/src/share/classes to jdk8/jaxp/src before updating it 
> to the current jaxp source (7160380).
> 
> webrev for the build files: 
> http://cr.openjdk.java.net/~joehw/jdk8/7160496/build/webrev/
> 
> webrevs for the src:  (result of hg mv src/share/classes src)   
> http://cr.openjdk.java.net/~joehw/jdk8/7160496/src/webrev/
> 
> Thanks,
> Joe

Re: Integer.parseInt

[Benedict Elliott Smith]

Sounds like a perfectly good reason! - and also that it should be a
relatively safe change to implement. Any volunteers? I'd be happy to, but I
expect the overhead for having a non-contributor do it would exceed the
actual work by several orders of magnitude.

On 11 April 2012 15:45, Rémi Forax  wrote:

> On 04/11/2012 04:18 PM, Benedict Elliott Smith wrote:
>
>> Hi,
>>
>> Looking at the source code, it doesn't appear as though there is any
>> reason
>> to require the input be a String - only length() and charAt() are called,
>> which are both declared by CharSequence. Is there a reason I can't fathom,
>> or was it an oversight? It would be nice to widen the type for this (and
>> potentially other equivalent methods).
>>
>
> Integer.parseInt (1.0 or 1.1) pre-date CharSequence (1.4),
> that's why it use a String an not a CharSequence.
>
> If you don't want to break all already compiled programs,
> you can't just replace String by CharSequence because the exact signature
> of the method
> (with the parameter types) is encoded in the bytecode.
> Joe Darcy write a cool blog post on that [1].
>
> The best here is to add new methods that takes a CharSequence, move the
> code that use
> a String in them and change the method that takes a String to delegate to
> the one that use
> a CharSequence.
>
> cheers,
> Rémi
> [1] 
> https://blogs.oracle.com/**darcy/entry/kinds_of_**compatibility
>
>
>

Re: Integer.parseInt

[Rémi Forax]

On 04/11/2012 04:18 PM, Benedict Elliott Smith wrote:

Hi,

Looking at the source code, it doesn't appear as though there is any reason
to require the input be a String - only length() and charAt() are called,
which are both declared by CharSequence. Is there a reason I can't fathom,
or was it an oversight? It would be nice to widen the type for this (and
potentially other equivalent methods).


Integer.parseInt (1.0 or 1.1) pre-date CharSequence (1.4),
that's why it use a String an not a CharSequence.

If you don't want to break all already compiled programs,
you can't just replace String by CharSequence because the exact 
signature of the method

(with the parameter types) is encoded in the bytecode.
Joe Darcy write a cool blog post on that [1].

The best here is to add new methods that takes a CharSequence, move the 
code that use
a String in them and change the method that takes a String to delegate 
to the one that use

a CharSequence.

cheers,
Rémi
[1] https://blogs.oracle.com/darcy/entry/kinds_of_compatibility

hg: jdk8/tl/jdk: 7071907: JDK: Full Debug Symbols

[daniel . daugherty]

Changeset: d922195b678d
Author:dcubed
Date:  2012-04-11 07:26 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d922195b678d

7071907: JDK: Full Debug Symbols
Summary: Add initial FDS support to some libraries and programs.
Reviewed-by: kamg, fparain, sspitsyn, dsamersoff

! make/com/sun/tools/attach/Makefile
! make/common/Defs-linux.gmk
! make/common/Defs-solaris.gmk
! make/common/Library.gmk
! make/common/Program.gmk
! make/common/Release.gmk
! make/java/instrument/Makefile
! make/java/java_crw_demo/Makefile
! make/java/java_hprof_demo/Makefile
! make/java/main/java/Makefile
! make/java/management/Makefile
! make/java/npt/Makefile
! make/java/verify/Makefile
! make/jpda/jdwp/Makefile
! make/jpda/transport/socket/Makefile
! make/launchers/Makefile.launcher
! make/mkdemo/jvmti/compiledMethodLoad/Makefile
! make/mkdemo/jvmti/gctest/Makefile
! make/mkdemo/jvmti/heapTracker/Makefile
! make/mkdemo/jvmti/heapViewer/Makefile
! make/mkdemo/jvmti/hprof/Makefile
! make/mkdemo/jvmti/minst/Makefile
! make/mkdemo/jvmti/mtrace/Makefile
! make/mkdemo/jvmti/versionCheck/Makefile
! make/mkdemo/jvmti/waiters/Makefile
! make/sun/tracing/dtrace/Makefile

Integer.parseInt

[Benedict Elliott Smith]

Hi,

Looking at the source code, it doesn't appear as though there is any reason
to require the input be a String - only length() and charAt() are called,
which are both declared by CharSequence. Is there a reason I can't fathom,
or was it an oversight? It would be nice to widen the type for this (and
potentially other equivalent methods).

Generics & Reification Was Code Review Request: 7157893: Warnings Cleanup in java.util.*

[Rémi Forax]

On 04/07/2012 02:35 AM, Stuart Marks wrote:
Hi Kurchi, I think we've converged on the code changes. Please prepare 
and post another webrev for a final cross-check before pushing.


What follows is I think merely residual disagreement over the 
philosophy of how to handle generic casts vs reification. :-)


I fully agree.



On 4/6/12 3:06 AM, Rémi Forax wrote:

On 04/05/2012 11:04 PM, Stuart Marks wrote:
I'm somewhat skeptical of making code changes now based on potential 
future
benefits when/if generics become reified. This was discussed before; 
see


http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000454.html 



In that message, John Rose said "If the best practices have to 
change, then
we'll have to change that code again. Or maybe the retrofit strategy 
will
have to take account of the existing code idioms. In any case, we'll 
cross
that bridge when we get to it. (Coping with reification in this case 
is a

decision to make tomorrow, not today.)"


I disagree with John. The main issue with generics nowadays is that
most of the people doesn't care about a cast to a type variable because
everybody knows about erasure. So codes are written with an 
implementation

glitch in mind.
Frankly, I don't know if reification will appear (yes it's a kind of 
magical)

or not
but I think it's a sloppy path to not consider all casts as equals.


In order to program effectively with generics, I think you have to 
understand erasure and its implications. It may have been an 
unfortunate choice, but erasure is part of the language and we have to 
deal with it and in some cases rely on it. I don't think it's merely 
an "implementation glitch."


Erased casts are an implementation glitch, not the erasure by itself.



The difficulty I have with reification is that while there are 
proposals floating around for how it could be done, nobody really 
knows how it will eventually turn out, nor whether it will actually be 
done. If it is eventually done, there will legal and illegal 
constructs, constructs that generate warnings, and perhaps a style 
guide for how to use reified generics properly.


Right now, we can *imagine* what these future rules might be, but it 
seems untenable to me to try to make today's code conform to those 
imaginary future rules, especially in the absence of tools to help 
support those rules.


There are several implementations that exist,
here is the publicly available papers.

M. Cimadamore and M. Viroli.
Reifying wildcards in Java using the EGO approach.
In SAC '07: Proceedings of the 2007 ACM symposium on
Applied computing, pages 1315{1322, New York, NY, USA,
2007. ACM.

M. Cimadamore and M. Viroli.
On Reication of Java Wildcards.
Science of Computer Programming, 2008




If unmaskNull return a V, the code of equals will upcast the value 
from Object

to V
to just after downcast it from V to Object,
I think it's better that unmask to return Object and upcast it to V 
when it's

necessary.


Certainly there are cases where there's a redundant downcast and 
upcast. In a reified world, will this be a significant expense? 
Really, I have no idea.


I don't think so, the equivalent cast with a reified type is cheap.



s'marks


Rémi

Re: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values

[Dmitry Samersoff]

Staffan,

MacosxOperatingSystem.c

Probably something went wrong with webrev:

 48 if (kr != KERN_SUCCESS) {
 49 return 0;
 50 }


 133 if (gettimeofday(&now, NULL)) {
 134return -1;
 135 }

-Dmitry


On 2012-04-11 11:52, Staffan Larsen wrote:

Thank you all for your comments!

New webrev here: http://cr.openjdk.java.net/~sla/7147848/webrev.01/

Changes:
- Fixed Dmitry's comments
- Updated TestTotalSwap.sh for Darwin (thanks Mandy)

I have verified the values manually by running a Java program (see
attachment) and comparing to top and other system utilities. I've also
compared output with a Linux system to compare magnitude of numbers. I
have run the various regression tests.

Thanks,
/Staffan




On 10 apr 2012, at 21:57, Mandy Chung wrote:


Staffan, Roger,

There isn't any undocumented semantics other than what the
specification for com.sun.management.OperatingSystemMXBean specifies
(that is indicated by its method name):
http://docs.oracle.com/javase/7/docs/jre/api/management/extension/index.html

As Roger suggests, you can do some sanity tests and compare the result
with native commands (top or other CLI). There are a few regression
tests in jdk/test/com/sun/management. In particular, you might want to
update test/com/sun/management/TestTotalSwap.sh to check the swap
space with a suitable macosx command, if there is one.

FYI. I'm not familiar with Mac OS X API and didn't review the code.

Mandy

On 4/10/2012 10:51 AM, rhoover wrote:

Scott, Steffan

(I am he one who put in the original lines of: return -1.0; // not
available being replaced by this patch)

I was reluctant to implement these functions because the linux code
was quite involved and it appeared to me that there might be some
additional semantics to what was implemented than what was indicated
by the function names alone.

I have not compared the code with the 'top' source, but it looks
plausible. As a sanity test, the function values being returned could
be printed by a java program and visually compared with the output of
'top' as a system is loaded up. It might also be wise to run the same
java program on other platforms to make sure that the magnitude of
the numbers is in the same ballpark.

On Apr 10, 2012, at 10:21 AM, Scott Kovatch wrote:


Regarding Apple, Roger Hoover would be a good person to look at
this, as he's spent more time in the Darwin levels of the VM. I
think he's still partially attached to the OpenJDK work.

-- Scott

On Apr 10, 2012, at 8:58 AM, Daniel D. Daugherty wrote:


Staffan,

I reviewed it and I think it looks OK. I tried looking at the code
in MacosxOperatingSystem.c relative to the Linux version, but I think
it is easily possible to miss something subtle here.

You might try a direct ping to Mandy Chung since M&M was her area.
You might also try a direct ping to Mike Swingler to get an Apple
reviewer.

Dan



On 4/10/12 3:30 AM, Staffan Larsen wrote:

Any takers for this review? (added core-libs-dev as well)

Thanks,
/Staffan

On 3 apr 2012, at 15:39, Staffan Larsen wrote:


Please review the following fix:

webrev:
http://cr.openjdk.java.net/~sla/7147848/webrev.00/
>
bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848

This fix implements the missing functionality in
UnixOperatingSystem for Mac OS X. Any feedback on the
implementation is welcome as I am not very familiar with the APIs
in Mac OS X.

I have verified that the changes build on all platforms through
JPRT. The correctness has been verified manually by looking in
JConsole and running the tests in
test/java/lang/management/OperatingSystemMXBean
test/com/sun/management/OperatingSystemMXBean.

Thanks,
/Staffan





--
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...

hg: jdk8/tl/langtools: 7154127: Inference cleanup: remove bound check analysis from visitors in Types.java

[maurizio . cimadamore]

Changeset: 6f0ed5a89c25
Author:mcimadamore
Date:  2012-04-11 10:50 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6f0ed5a89c25

7154127: Inference cleanup: remove bound check analysis from visitors in 
Types.java
Summary: Remove bound checking rules from recursive subtype visitors in 
Types.java and replace with centralized bound-checking logic
Reviewed-by: jjg, dlsmith

! src/share/classes/com/sun/tools/javac/code/Type.java
! src/share/classes/com/sun/tools/javac/code/Types.java
! src/share/classes/com/sun/tools/javac/comp/Infer.java
! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! test/tools/javac/Diagnostics/6722234/T6722234b_1.out
! test/tools/javac/Diagnostics/6722234/T6722234b_2.out
! test/tools/javac/Diagnostics/6799605/T6799605.out
! test/tools/javac/cast/7123100/T7123100a.out
! test/tools/javac/diags/examples.not-yet.txt
! test/tools/javac/diags/examples/CantApplyDiamond1.java
! test/tools/javac/diags/examples/IncompatibleTypes1.java
+ test/tools/javac/diags/examples/InferNoConformingAssignment.java
- test/tools/javac/diags/examples/InferredDoNotConformToBounds.java
+ test/tools/javac/diags/examples/InferredDoNotConformToEq.java
+ test/tools/javac/diags/examples/InferredDoNotConformToLower.java
+ test/tools/javac/diags/examples/InferredDoNotConformToUpper.java
! test/tools/javac/diags/examples/InvalidInferredTypes.java
! test/tools/javac/diags/examples/WhereCaptured.java
! test/tools/javac/diags/examples/WhereCaptured1.java
+ test/tools/javac/diags/examples/WhereFreshTvar.java
! test/tools/javac/generics/diamond/neg/Neg06.out
! test/tools/javac/generics/diamond/neg/Neg07.out
! test/tools/javac/generics/inference/6315770/T6315770.out
! test/tools/javac/generics/inference/6611449/T6611449.out
! test/tools/javac/generics/inference/6638712/T6638712b.out
! test/tools/javac/generics/inference/6638712/T6638712d.out
! test/tools/javac/generics/inference/6638712/T6638712e.out
! test/tools/javac/generics/inference/6650759/T6650759m.out
! test/tools/javac/generics/inference/7086601/T7086601a.out
+ test/tools/javac/generics/inference/7154127/T7154127.java
+ test/tools/javac/generics/inference/7154127/T7154127.out

Re: RFR(M): 7147848: [macosx] com.sun.management.UnixOperatingSystem uses hardcoded dummy values

[Staffan Larsen]

Thank you all for your comments!

New webrev here: http://cr.openjdk.java.net/~sla/7147848/webrev.01/

Changes:
- Fixed Dmitry's comments
- Updated TestTotalSwap.sh for Darwin (thanks Mandy)

I have verified the values manually by running a Java program (see attachment) 
and comparing to top and other system utilities. I've also compared output with 
a Linux system to compare magnitude of numbers. I have run the various 
regression tests.

Thanks,
/Staffan



On 10 apr 2012, at 21:57, Mandy Chung wrote:

> Staffan, Roger,
> 
> There isn't any undocumented semantics other than what the specification for 
> com.sun.management.OperatingSystemMXBean specifies (that is indicated by its 
> method name):
>   http://docs.oracle.com/javase/7/docs/jre/api/management/extension/index.html
> 
> As Roger suggests, you can do some sanity tests and compare the result with 
> native commands (top or other CLI).  There are a few regression tests in 
> jdk/test/com/sun/management.   In particular, you might want to update 
> test/com/sun/management/TestTotalSwap.sh to check the swap space with a 
> suitable macosx command, if there is one.
> 
> FYI.  I'm not familiar with Mac OS X API and didn't review the code.
> 
> Mandy
> 
> On 4/10/2012 10:51 AM, rhoover wrote:
>> Scott, Steffan
>> 
>> (I am he one who put in the original lines of: return -1.0; // not available 
>> being replaced by this patch)
>> 
>> I was reluctant to implement these functions because the linux code was 
>> quite involved and it appeared to me that there might be some additional 
>> semantics to what was implemented than what was indicated by the function 
>> names alone.
>> 
>> I have not compared the code with the 'top' source, but it looks plausible.  
>> As a sanity test, the function values being returned could be printed by a 
>> java program and visually compared with the output of 'top' as a system is 
>> loaded up.  It might also be wise to run the same java program on other 
>> platforms to make sure that the magnitude of the numbers is in the same 
>> ballpark.
>> 
>> On Apr 10, 2012, at10:21 AM, Scott Kovatch wrote:
>> 
>>> Regarding Apple, Roger Hoover would be a good person to look at this, as 
>>> he's spent more time in the Darwin levels of the VM. I think he's still 
>>> partially attached to the OpenJDK work.
>>> 
>>> -- Scott
>>> 
>>> On Apr 10, 2012, at 8:58 AM, Daniel D. Daugherty wrote:
>>> 
 Staffan,
 
 I reviewed it and I think it looks OK. I tried looking at the code
 in MacosxOperatingSystem.c relative to the Linux version, but I think
 it is easily possible to miss something subtle here.
 
 You might try a direct ping to Mandy Chung since M&M was her area.
 You might also try a direct ping to Mike Swingler to get an Apple
 reviewer.
 
 Dan
 
 
 
 On 4/10/12 3:30 AM, Staffan Larsen wrote:
> Any takers for this review? (added core-libs-dev as well)
> 
> Thanks,
> /Staffan
> 
> On 3 apr 2012, at 15:39, Staffan Larsen wrote:
> 
>> Please review the following fix:
>> 
>> webrev: 
>> http://cr.openjdk.java.net/~sla/7147848/webrev.00/
>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7147848
>> 
>> This fix implements the missing functionality in UnixOperatingSystem for 
>> Mac OS X. Any feedback on the implementation is welcome as I am not very 
>> familiar with the APIs in Mac OS X.
>> 
>> I have verified that the changes build on all platforms through JPRT. 
>> The correctness has been verified manually by looking in JConsole and 
>> running the tests in test/java/lang/management/OperatingSystemMXBean 
>> test/com/sun/management/OperatingSystemMXBean.
>> 
>> Thanks,
>> /Staffan

Re: New constructor in sun.tools.java.ClassPath builds a path using File.separator instead of File.pathSeparatorChar

[Deven You]

On 04/10/2012 04:12 PM, Alan Bateman wrote:

On 09/04/2012 10:32, Deven You wrote:

:

The issue is reported by one of our test team which maintains  a set 
of ORB test cases.
Okay but I guess I'm still a bit curious as it's not obvious that rmic 
(or rmic --iiop) invokes toString, maybe this is a white box test or a 
test that is using sun.tools.java.*?


-Alan.


Hi Alan,

Though I am not very sure, I guess it is a white box test. I find some 
code snippet which may cause this errors, like:


sun.misc.URLClassPath.pathToURLs(classPath.toString()));

I think if anyone use above like code, it will fail.

Thanks a lot!

--
Best Regards,

Deven

sun.management.Agent: the properties.putAll API may fail with ConcurrentModifcationException on multi-thread scenario

[Deven You]

Hi core-libs-devs,

I am not sure if sun.management.Agent belongs to jmx-dev mailing list, 
if so please anyone tell me.


This issue is that the sun.management.Agent.loadManagementProperties() 
will invoke properties.putAll which will throw 
ConcurrentModifcationException if there are other threads which modify 
the properties concurrently.


I have made a patch[1] which synchronize the sysProps so that putAll can 
work on multi-thread scenario. The test case is also available in [1].


Thanks a lot!

[1] http://cr.openjdk.java.net/~littlee/OJDK-256/webrev.00 



--
Best Regards,

Deven