From christos at zoulas.com  Wed Jul  1 00:18:31 2009
From: christos at zoulas.com (Christos Zoulas)
Date: Tue, 30 Jun 2009 20:18:31 -0400
Subject: Review request for 5049299
In-Reply-To: <1ccfd1c10906301639j68a389a8w7cac8c235d72c5c0@mail.gmail.com>
	from Martin Buchholz (Jun 30,  4:39pm)
Message-ID: <20090701001831.C84775654E@rebar.astron.com>

On Jun 30,  4:39pm, martinrb at google.com (Martin Buchholz) wrote:
-- Subject: Re: Review request for 5049299

| In the JDK...
| We close all non-relevant file descriptors in the child instead of relying
| on
| having the FD_CLOEXEC bit set properly for every fd in the parent.
| 
| The technique of choice appears to be to read /proc/self/fd and
| close all the fds found therein.
| That's even portable between linux and solaris!

Well, on solaris it is best to use closefrom(3C). I think some BSDs have it
too, AIX, IRIX. So perhaps detect if it is there and use that instead (
or fcntl(fd, F_CLOSEM) if it exists.

christos


From gnu_andrew at member.fsf.org  Wed Jul  1 00:23:47 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 1 Jul 2009 01:23:47 +0100
Subject: timsort
In-Reply-To: <1ccfd1c10906301101w43a20d11me6350d7b0706aaca@mail.gmail.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<17c6771e0906300924m435356aah37b63f98baf5b2ea@mail.gmail.com>
	<1ccfd1c10906301101w43a20d11me6350d7b0706aaca@mail.gmail.com>
Message-ID: <17c6771e0906301723q5dc43f5ft31eaa0865a7a0758@mail.gmail.com>

2009/6/30 Martin Buchholz <martinrb at google.com>:
>
>
> On Tue, Jun 30, 2009 at 09:24, Andrew John Hughes
> <gnu_andrew at member.fsf.org> wrote:
>>
>> 2009/6/30 Martin Buchholz <martinrb at google.com>:
>>
>> > (There is the deeper governance issue of who gets to make
>> > such decisions.? I would like most of such decisions to be made
>> > by the "group" of engineers who do the work.? For
>> > collections/concurrency,
>> > such a group has worked informally for many years.)
>> >
>>
>> OpenJDK is (or at least should now be) a community-driven open source
>> project. ?And so, the community as a whole should be making such
>> decisions, not just those who happen to be employed by Sun.
>
> Right.? There is a problem when different sets of contributors have
> different
> objectives for things like
> compatibility, portability, stability, benchmark performance....
>

Sure, you're right.  My point was just that the decisions you mention
should be made in the open by discussing the issues on the mailing
lists (as I believe we are doing).  I still expect those involved to
come down to the group of interested engineers as you mentioned, who
would be able to obtain a suitable consensus on how to move forward.
I would just hope that these days such a group would not be
constrained by the companies the engineers choose to work for.  I
think we're starting to get there and doing so has advantages for all,
whether at Sun, Google, Red Hat or elsewhere.

> It might be that a significant contributor (like Sun or IcedTea) would
> maintain
> a separate set of patches essentially forever, since they would not be
> acceptable to the greater community.? Oh, I guess that's already happened,
> eh?

In some cases, yes.  IcedTea has a hefty pile of patches, but we're
trying to push most of them upstream.  There are obviously ones that
are too specific though and which it wouldn't make sense to send
upstream, and I'm sure the same is true at Google and Sun.  Of course,
all of ours are there for all to see :) It would be nice if others did
the same too, a public Google-maintained OpenJDK forest seems a nice
idea to me.

>
> There's also the issue of the size of the project.? Is OpenJDK a "project",
> or is it an aggregator of projects maintained by various third parties,
> like a Linux distro?? Given how the code base has grown, at least a large
> number of components should be treated in the latter way.
> It is already the case, I believe, that the JAX* code is essentially
> imported
> unchanged from upstream maintainers.
>

It's certainly not on the scale of a distro, nor is it simply an
aggregator.  It does depend on external code, just like pretty much
any significant project.  Anything else would be recreating the wheel
and thus bad software engineering.  There is also a heck of a lot of
new code being created here, which isn't true of distros (or shouldn't
be in any case!!!!)

The jdk, langtools and hotspot repos are developed locally.  JAXWS,
JAXP and CORBA are all imports (from Glassfish I think).  I think in
the long run it would be better if these were handled as such (as has
been suggested on one or other of these lists), rather than
maintaining the numerous local copies.  I do know there is a plan to
pull from upstream before JDK7.  I don't know if patches ever go the
opposite direction though.

In turn, IcedTea is aggregating OpenJDK with other stuff too of course
-- like a plugin, webstart functionality, additional platform support,
etc.

> Martin
>
>



-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From roland at redhat.com  Wed Jul  1 00:10:56 2009
From: roland at redhat.com (Roland McGrath)
Date: Tue, 30 Jun 2009 17:10:56 -0700 (PDT)
Subject: Review request for 5049299
In-Reply-To: Martin Buchholz's message of  Tuesday, 30 June 2009 16:58:02 -0700
	<1ccfd1c10906301658l6bc57155t20c3630a80d82263@mail.gmail.com>
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10906091244u14607dcesc40fc6017adc7808@mail.gmail.com>
	<4A311337.9070706@sun.com>
	<1ccfd1c10906111416x1b0fveb52eb9d3db56ded@mail.gmail.com>
	<1ccfd1c10906221745u87082b0m80dd3b79b4646bdf@mail.gmail.com>
	<4A40E7C0.5080308@redhat.com>
	<1ccfd1c10906271035g660800a5n7de04efc6f1ce504@mail.gmail.com>
	<20090628023345.C970A420F6@magilla.sf.frob.com>
	<1ccfd1c10906291823p366255e5t678bcade6c5aa08@mail.gmail.com>
	<20090630022822.2F69F420F6@magilla.sf.frob.com>
	<1ccfd1c10906301658l6bc57155t20c3630a80d82263@mail.gmail.com>
Message-ID: <20090701001056.ED8CB21D57@magilla.sf.frob.com>

> You write "It's all the same "clone" code in the kernel."
> and that may be true, but I'm thinking about the glibc wrappers around them.

I only made that point in response to your contrasts between "a dedicated
vfork syscall number" and "a clone call passed CLONE_VFORK | CLONE_VM |
SIGCHLD", for which the kernel's semantics are completely identical.

> In particular, it seems to me that vfork and clone(CLONE_VM|CLONE_VFORK)
> should have similar assembly wrappers around them.  But the
> vfork code uses SAVE_PID/RESTORE_PID which frobs only the pid, not the tid,
> while clone used RESET_PID which frobs both the pid and tid.
> It seems to me they should share common infrastructure.

That makes sense to me, but I have not looked closely at that logic.


Thanks,
Roland


From Jean-Christophe.Collet at Sun.COM  Wed Jul  1 11:23:52 2009
From: Jean-Christophe.Collet at Sun.COM (Jean-Christophe Collet)
Date: Wed, 01 Jul 2009 13:23:52 +0200
Subject: hg: jdk7/tl/jdk: 6811297: Add more logging to HTTP
	protocol	handler
In-Reply-To: <7d7138c10906251017t4aafc6c5r6939ac979e35cc3b@mail.gmail.com>
References: <20090625170859.70BC6E0FA@hg.openjdk.java.net>
	<7d7138c10906251017t4aafc6c5r6939ac979e35cc3b@mail.gmail.com>
Message-ID: <4A4B4748.1020906@sun.com>

Yes, it would be nice and there are actually already 2 RFEs covering this:
4640805: Protocol and content handlers SPI
6249864: make it easier to write custom url handlers

However this is no small task, specially considering the compatibility 
and security constraints.
So far resources (or lack of thereof) have prevented us of working on it.

Jim Andreou wrote:
> Hi,
>
> A quick note: Wouldn't it be nice if clients could add URL handling 
> interceptors and monitor incoming/outgoing data themselves? For any 
> URL protocol they would be interested into, not http in particular. 
> Recently I looked into the existing URL protocol handling architecture 
> (e.g. [1], which promises a new era for protocol handlers, but it 
> seems that the existing support is cumbersome and  restricting - 
> sorry, I can't elaborate right now) but it seems to make any such 
> scenario impossible. 
>
> Any comments?
>
> Thanks,
>
> Dimitris Andreou
>
> [1] http://java.sun.com/developer/onlineTraining/protocolhandlers/
>
> 2009/6/25 <jean-christophe.collet at sun.com 
> <mailto:jean-christophe.collet at sun.com>>
>
>     Changeset: 70c0a927e21a
>     Author:    jccollet
>     Date:      2009-06-25 18:56 +0200
>     URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/70c0a927e21a
>
>     6811297: Add more logging to HTTP protocol handler
>     Summary: Added extra logging to HttpURLConnection and HttpClient.
>     Added a capture tool.
>     Reviewed-by: chegar
>
>     ! make/sun/net/FILES_java.gmk
>     + src/share/classes/sun/net/www/http/HttpCapture.java
>     + src/share/classes/sun/net/www/http/HttpCaptureInputStream.java
>     + src/share/classes/sun/net/www/http/HttpCaptureOutputStream.java
>     ! src/share/classes/sun/net/www/http/HttpClient.java
>     + src/share/classes/sun/net/www/protocol/http/HttpLogFormatter.java
>     ! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
>
>



From dl at cs.oswego.edu  Wed Jul  1 12:27:50 2009
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 01 Jul 2009 08:27:50 -0400
Subject: Faster HashMap implementation
In-Reply-To: <4A4A8D00.8000506@cs.oswego.edu>
References: <f813797e0906031621l650feb9erd313d6a3872a2941@mail.gmail.com>		<4A2D3729.3040904@cs.oswego.edu>		<f813797e0906080959p65f04f94t170249f285e55597@mail.gmail.com>		<4A2E5109.4050804@cs.oswego.edu>		<f813797e0906090743oca8faf7he2c066b125c190ef@mail.gmail.com>		<4A40FD16.6040503@cs.oswego.edu>	<f813797e0906262054n56d251b7w5fbf4e163b565a8a@mail.gmail.com>
	<4A4A8D00.8000506@cs.oswego.edu>
Message-ID: <4A4B5646.5080606@cs.oswego.edu>

While I'm posting in-progress stuff, here are some other notes on hash
maps:

First, some observations about usage (repeating some
already posted):

Via some dated but probably still valid dynamic measurments:
    Ops: Approx 84% read, 15% add/modify, 1% remove
    Sizes: Peak at 0, 1, 2, then mostly flat distribution across all others
Static guesses from frequencies of code forms, mainly via google code search
   Key types
     50-60% Strings
     10-20% Numbers -- mainly Integer, then Long,  then others
     10-20% Identity-based (no override of equals/hashCode)
     10-30% eveything else
   Reads might be around 70% get, 30% traverse?
   get: At least 80% successful (no null checks on get)
   Iterators: Probably less than 20% Entry, others about half key vs value
   Puts: typically add, not modify

The tables below (from MapMicrobenchmark) show that cache misses
completely dominate performance for large maps. You'd like to both
push out the sizes for which they come into play, and lessen the
number of indirections (thus misses) even when they do. HashMapV2
mostly does the latter. Of course, for cache misses to dominate, you
also need good key hashing and collision strategies to cope with
possibly poor hashCode()'s.

Times are approximately nanosecs per element/op.  Here are runs on an
Intel x86 linux 2.6.24-23 with jdk6 -server.
Absolute times vary on other platforms but show the same patterns (*).

HashMap:
Type/Size:      36     144     576    2304    9216   36864  147456  589824
BigDecimal      40      37      43      47      57     174     267     317
BigInteger      39      34      38      39      48     187     247     288
String          37      34      38      42      54     149     227     253
Double          41      36      39      44      49      80     219     250
Float           40      38      41      44      48      95     216     267
Long            34      29      33      34      43      74     194     242
Integer         38      33      36      39      46      70     199     233
Object          36      33      35      39      47      64     215     275

average         38      34      37      41      49     111     223     265

HashMapV2:
Type/Size:      36     144     576    2304    9216   36864  147456  589824
BigDecimal      34      34      40      44      58     146     255     286
BigInteger      28      25      29      34      44     151     220     243
String          34      29      34      40      59     136     208     238
Double          37      32      32      44      46      55     180     192
Float           34      37      38      42      42      67     165     246
Long            26      21      22      29      32      40     123     147
Integer         29      25      30      37      46      60     137     157
Object          34      31      33      41      49      64     196     250

average         32      29      32      38      47      89     185     219

Here are some more details listed across some operation categories
(via updated MapCheck) using as keys, English words (Strings) from a
big dictionary.  Times are scaled differently than above, and these
runs are from AMD-x86/solaris, also typical of others:

                         HashMap  :     V2
Access Present         :    213  :    200
Add    Absent          :    265  :    245
Modify Present         :    231  :    199
Remove Present         :    111  :    101
Search Absent          :    119  :     93
Traverse access entry  :    173  :    137
Traverse access key/val:    147  :     87


(*) At least on Solaris jdk6u14, adding the -XX:+AggressiveOpts option
also seems to enable the specialized Integer version of HashMap, which
improves performance on some tests but worsens on others. On all
platforms, the -XX:+AggressiveOpts switch seems to lead to more
run-to-run variation.

Here's synosis of MapMicrobenchmark pasted from javadoc:

  * A micro-benchmark with key types and operation mixes roughly
  * corresponding to some real programs.
  *
  * The main results are a table of approximate nanoseconds per
  * element-operation (averaged across get, put etc) for each type,
  * across a range of map sizes.
  *
  * The program includes a bunch of microbenchmarking safeguards that
  * might underestimate typical performance. For example, by using many
  * different key types and exercising them in warmups it disables most
  * dynamic type specialization.  Some test classes, like Float and
  * BigDecimal are included not because they are commonly used as keys,
  * but because they can be problematic for some map implementations.
  *
  * By default, it creates and inserts in order dense numerical keys
  * and searches for keys in scrambled order. Use "r" as second arg to
  * instead use random numerical values, and "s" as third arg to search
  * in insertion order.


From alex14n at gmail.com  Wed Jul  1 12:50:49 2009
From: alex14n at gmail.com (Alex Yakovlev)
Date: Wed, 1 Jul 2009 16:50:49 +0400
Subject: Faster HashMap implementation
In-Reply-To: <4A4A8D00.8000506@cs.oswego.edu>
References: <f813797e0906031621l650feb9erd313d6a3872a2941@mail.gmail.com>
	<4A2D3729.3040904@cs.oswego.edu>
	<f813797e0906080959p65f04f94t170249f285e55597@mail.gmail.com>
	<4A2E5109.4050804@cs.oswego.edu>
	<f813797e0906090743oca8faf7he2c066b125c190ef@mail.gmail.com>
	<4A40FD16.6040503@cs.oswego.edu>
	<f813797e0906262054n56d251b7w5fbf4e163b565a8a@mail.gmail.com>
	<4A4A8D00.8000506@cs.oswego.edu>
Message-ID: <f813797e0907010550v5c65c2fdvabab7575f01092b6@mail.gmail.com>

Doug,

Checking key reference equality before hashcode looks like a big win.

Have you considered using balancing tree instead of bit trie?
This could decrease look depth from number of hash bits to log2(tree size).

Also, there could be a sence in using adjacent table cell for key/value if it's
not used. Maybe also without a hashcode check for less cache misses.
In practice this gives ~4-5% performance for get(). In theory, when
70% of gets are resolved at first try, 23% on second, assuming that
adjacent cell is empty in 50% cases, and in best case (referential equality)
we'll have 1 cache miss instead of 3, thus .23*.5*(2/3) = 7.67%
in worst case (2 cache misses instead of 4 with hashcode check) +5.75%

On Wed, Jul 1, 2009 at 2:09 AM, Doug Lea<dl at cs.oswego.edu> wrote:
>
> Inspired by the combination of Alex's efforts and ongoing
> work on concurrent caches, I put together a version
> of HashMap (called HashMapV2 for now) with a snapshot at
> ?http://gee.cs.oswego.edu/dl/wwwtmp/HashMapV2.java
> (This retains the openjdk GPL header etc.)


From Michael.McMahon at Sun.COM  Wed Jul  1 12:55:02 2009
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Wed, 01 Jul 2009 13:55:02 +0100
Subject: Review request for 5049299
In-Reply-To: <1ccfd1c10906301639j68a389a8w7cac8c235d72c5c0@mail.gmail.com>
References: <4A1678DB.9010209@sun.com> <4A311337.9070706@sun.com>
	<1ccfd1c10906111416x1b0fveb52eb9d3db56ded@mail.gmail.com>
	<1ccfd1c10906221745u87082b0m80dd3b79b4646bdf@mail.gmail.com>
	<4A40E7C0.5080308@redhat.com>
	<1ccfd1c10906271035g660800a5n7de04efc6f1ce504@mail.gmail.com>
	<20090628023345.C970A420F6@magilla.sf.frob.com>
	<1ccfd1c10906291823p366255e5t678bcade6c5aa08@mail.gmail.com>
	<20090630022822.2F69F420F6@magilla.sf.frob.com>
	<4A49DF55.5090807@sun.com>
	<1ccfd1c10906301639j68a389a8w7cac8c235d72c5c0@mail.gmail.com>
Message-ID: <4A4B5CA6.90607@sun.com>

Can we decide on a plan for this issue? I'd like to have
it resolved in good time for M5.

Architecturally, the solution for Solaris is clear I think:
posix_spawn() of helper program which exec()'s the final target.

So, can we recap on what the situation is for Linux?

Is it vfork() plus exec()?
But ,if (as the man page suggests) vfork() is just a special
case of clone(), then are we sure there still isn't too much
"stuff happening" between clone()/vfork() and exec() ?

Maybe, if this question isn't resolved (or resolvable) soon
then should we go ahead with a Solaris only fix?

- Michael.


From martinrb at google.com  Wed Jul  1 14:56:52 2009
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 1 Jul 2009 07:56:52 -0700
Subject: Review request for 5049299
In-Reply-To: <4A4B5CA6.90607@sun.com>
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10906221745u87082b0m80dd3b79b4646bdf@mail.gmail.com>
	<4A40E7C0.5080308@redhat.com>
	<1ccfd1c10906271035g660800a5n7de04efc6f1ce504@mail.gmail.com>
	<20090628023345.C970A420F6@magilla.sf.frob.com>
	<1ccfd1c10906291823p366255e5t678bcade6c5aa08@mail.gmail.com>
	<20090630022822.2F69F420F6@magilla.sf.frob.com>
	<4A49DF55.5090807@sun.com>
	<1ccfd1c10906301639j68a389a8w7cac8c235d72c5c0@mail.gmail.com>
	<4A4B5CA6.90607@sun.com>
Message-ID: <1ccfd1c10907010756u23fb67d8i6be4bd95ae43f837@mail.gmail.com>

Sorry this is taking so long to get in.
The current situation is that I have two changes out for review.
http://cr.openjdk.java.net/~martin/vfork-exec/
http://cr.openjdk.java.net/~martin/RESTARTABLE/
That appear to work on Linux.
Michael, please file bugs in bugtraq and review.
Then we put in your processhelper code.
We have some issues about how best to
organize the processhelper code that
we still need to resolve.

(The recent email involving glibc are not
directly relevant since we won't be able
to benefit from any glibc changes nearterm)

I've been thinking we should go further than having
compile-time support for choosing the fork-method
and add a system property to select among the
4 different ways of starting a subprocess.
The kinds of changes being made will still be risky
and it would be nice to have a way to revert to the
safer fork() strategy.

Martin

On Wed, Jul 1, 2009 at 05:55, Michael McMahon <Michael.McMahon at sun.com>wrote:

> Can we decide on a plan for this issue? I'd like to have
> it resolved in good time for M5.
>
> Architecturally, the solution for Solaris is clear I think:
> posix_spawn() of helper program which exec()'s the final target.
>
> So, can we recap on what the situation is for Linux?
>
> Is it vfork() plus exec()?
> But ,if (as the man page suggests) vfork() is just a special
> case of clone(), then are we sure there still isn't too much
> "stuff happening" between clone()/vfork() and exec() ?
>
> Maybe, if this question isn't resolved (or resolvable) soon
> then should we go ahead with a Solaris only fix?
>
> - Michael.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090701/3ab1275d/attachment.html>

From martinrb at google.com  Wed Jul  1 14:56:52 2009
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 1 Jul 2009 07:56:52 -0700
Subject: Review request for 5049299
In-Reply-To: <4A4B5CA6.90607@sun.com>
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10906221745u87082b0m80dd3b79b4646bdf@mail.gmail.com>
	<4A40E7C0.5080308@redhat.com>
	<1ccfd1c10906271035g660800a5n7de04efc6f1ce504@mail.gmail.com>
	<20090628023345.C970A420F6@magilla.sf.frob.com>
	<1ccfd1c10906291823p366255e5t678bcade6c5aa08@mail.gmail.com>
	<20090630022822.2F69F420F6@magilla.sf.frob.com>
	<4A49DF55.5090807@sun.com>
	<1ccfd1c10906301639j68a389a8w7cac8c235d72c5c0@mail.gmail.com>
	<4A4B5CA6.90607@sun.com>
Message-ID: <1ccfd1c10907010756u23fb67d8i6be4bd95ae43f837@mail.gmail.com>

Sorry this is taking so long to get in.
The current situation is that I have two changes out for review.
http://cr.openjdk.java.net/~martin/vfork-exec/
http://cr.openjdk.java.net/~martin/RESTARTABLE/
That appear to work on Linux.
Michael, please file bugs in bugtraq and review.
Then we put in your processhelper code.
We have some issues about how best to
organize the processhelper code that
we still need to resolve.

(The recent email involving glibc are not
directly relevant since we won't be able
to benefit from any glibc changes nearterm)

I've been thinking we should go further than having
compile-time support for choosing the fork-method
and add a system property to select among the
4 different ways of starting a subprocess.
The kinds of changes being made will still be risky
and it would be nice to have a way to revert to the
safer fork() strategy.

Martin

On Wed, Jul 1, 2009 at 05:55, Michael McMahon <Michael.McMahon at sun.com>wrote:

> Can we decide on a plan for this issue? I'd like to have
> it resolved in good time for M5.
>
> Architecturally, the solution for Solaris is clear I think:
> posix_spawn() of helper program which exec()'s the final target.
>
> So, can we recap on what the situation is for Linux?
>
> Is it vfork() plus exec()?
> But ,if (as the man page suggests) vfork() is just a special
> case of clone(), then are we sure there still isn't too much
> "stuff happening" between clone()/vfork() and exec() ?
>
> Maybe, if this question isn't resolved (or resolvable) soon
> then should we go ahead with a Solaris only fix?
>
> - Michael.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090701/3ab1275d/attachment-0001.html>

From aph at redhat.com  Wed Jul  1 15:03:37 2009
From: aph at redhat.com (Andrew Haley)
Date: Wed, 01 Jul 2009 16:03:37 +0100
Subject: Review request for 5049299
In-Reply-To: <1ccfd1c10907010756u23fb67d8i6be4bd95ae43f837@mail.gmail.com>
References: <4A1678DB.9010209@sun.com>	<1ccfd1c10906221745u87082b0m80dd3b79b4646bdf@mail.gmail.com>	<4A40E7C0.5080308@redhat.com>	<1ccfd1c10906271035g660800a5n7de04efc6f1ce504@mail.gmail.com>	<20090628023345.C970A420F6@magilla.sf.frob.com>	<1ccfd1c10906291823p366255e5t678bcade6c5aa08@mail.gmail.com>	<20090630022822.2F69F420F6@magilla.sf.frob.com>	<4A49DF55.5090807@sun.com>	<1ccfd1c10906301639j68a389a8w7cac8c235d72c5c0@mail.gmail.com>	<4A4B5CA6.90607@sun.com>
	<1ccfd1c10907010756u23fb67d8i6be4bd95ae43f837@mail.gmail.com>
Message-ID: <4A4B7AC9.9070402@redhat.com>

Martin Buchholz wrote:

> I've been thinking we should go further than having
> compile-time support for choosing the fork-method
> and add a system property to select among the
> 4 different ways of starting a subprocess.
> The kinds of changes being made will still be risky
> and it would be nice to have a way to revert to the
> safer fork() strategy.

That's very sensible.

Andrew.


From Michael.McMahon at Sun.COM  Wed Jul  1 15:47:23 2009
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Wed, 01 Jul 2009 16:47:23 +0100
Subject: Review request for 5049299
In-Reply-To: <1ccfd1c10907010756u23fb67d8i6be4bd95ae43f837@mail.gmail.com>
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10906221745u87082b0m80dd3b79b4646bdf@mail.gmail.com>
	<4A40E7C0.5080308@redhat.com>
	<1ccfd1c10906271035g660800a5n7de04efc6f1ce504@mail.gmail.com>
	<20090628023345.C970A420F6@magilla.sf.frob.com>
	<1ccfd1c10906291823p366255e5t678bcade6c5aa08@mail.gmail.com>
	<20090630022822.2F69F420F6@magilla.sf.frob.com>
	<4A49DF55.5090807@sun.com>
	<1ccfd1c10906301639j68a389a8w7cac8c235d72c5c0@mail.gmail.com>
	<4A4B5CA6.90607@sun.com>
	<1ccfd1c10907010756u23fb67d8i6be4bd95ae43f837@mail.gmail.com>
Message-ID: <4A4B850B.2030006@sun.com>

Martin Buchholz wrote:
> Sorry this is taking so long to get in.
> The current situation is that I have two changes out for review.
> http://cr.openjdk.java.net/~martin/vfork-exec/ 
> <http://cr.openjdk.java.net/%7Emartin/vfork-exec/>
6856589: Make process launching configurable

I think I agree with making this configurable via system property.

> http://cr.openjdk.java.net/~martin/RESTARTABLE/ 
> <http://cr.openjdk.java.net/%7Emartin/RESTARTABLE/>
6856590: Use RESTARTABLE in UNIXProcess_md.c

webrev looks fine.

Thanks,
Michael.


From martinrb at google.com  Wed Jul  1 23:28:25 2009
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 1 Jul 2009 16:28:25 -0700
Subject: Review request for 5049299
In-Reply-To: <4A4B5CA6.90607@sun.com>
References: <4A1678DB.9010209@sun.com>
	<1ccfd1c10906221745u87082b0m80dd3b79b4646bdf@mail.gmail.com>
	<4A40E7C0.5080308@redhat.com>
	<1ccfd1c10906271035g660800a5n7de04efc6f1ce504@mail.gmail.com>
	<20090628023345.C970A420F6@magilla.sf.frob.com>
	<1ccfd1c10906291823p366255e5t678bcade6c5aa08@mail.gmail.com>
	<20090630022822.2F69F420F6@magilla.sf.frob.com>
	<4A49DF55.5090807@sun.com>
	<1ccfd1c10906301639j68a389a8w7cac8c235d72c5c0@mail.gmail.com>
	<4A4B5CA6.90607@sun.com>
Message-ID: <1ccfd1c10907011628o68bca87ei76f9a92e3f0af970@mail.gmail.com>

I chatted with Tim Bell, and we have go-ahead to put changes into tl
after July 13.

I intend to do some more work on clone-exec,
putting changes into my mq and keeping webrevs at
http://cr.openjdk.java.net/~martin/

Here's a small paranoia increase change I am making to vfork-exec:
- suggest that gcc not inline startChild
- suggest that the compiler not keep resultPid in a register
- use CLONE_VFORK with clone, as suggested by a colleague.
  The parent has to wait for the child to proceed anyways, and
  this should be more robust.

diff --git a/src/solaris/native/java/lang/UNIXProcess_md.c
b/src/solaris/native/java/lang/UNIXProcess_md.c
--- a/src/solaris/native/java/lang/UNIXProcess_md.c
+++ b/src/solaris/native/java/lang/UNIXProcess_md.c
@@ -718,7 +718,12 @@
 /**
  * Start a child process running function childProcess.
  * This function only returns in the parent.
+ * We are unusually paranoid; use of clone/vfork is
+ * especially likely to tickle gcc/glibc bugs.
  */
+#ifdef __attribute_noinline__  /* See: sys/cdefs.h */
+__attribute_noinline__
+#endif
 static pid_t
 startChild(ChildStuff *c) {
 #if START_CHILD_USE_CLONE
@@ -733,8 +738,7 @@
         return -1;
     return clone(childProcess,
                  c->clone_stack + START_CHILD_CLONE_STACK_SIZE,
-                 /* CLONE_VFORK | // works, but unnecessary */
-                 CLONE_VM | SIGCHLD, c);
+                 CLONE_VFORK | CLONE_VM | SIGCHLD, c);
 #else
   #if START_CHILD_USE_VFORK
     /*
@@ -743,7 +747,7 @@
      * as suggested by the scary gcc warning:
      *  warning: variable 'foo' might be clobbered by 'longjmp' or 'vfork'
      */
-    pid_t resultPid = vfork();
+    volatile pid_t resultPid = vfork();
   #else
     /*
      * From Solaris fork(2): In Solaris 10, a call to fork() is


Martin

On Wed, Jul 1, 2009 at 05:55, Michael McMahon<Michael.McMahon at sun.com> wrote:
> Can we decide on a plan for this issue? I'd like to have
> it resolved in good time for M5.
>
> Architecturally, the solution for Solaris is clear I think:
> posix_spawn() of helper program which exec()'s the final target.
>
> So, can we recap on what the situation is for Linux?
>
> Is it vfork() plus exec()?
> But ,if (as the man page suggests) vfork() is just a special
> case of clone(), then are we sure there still isn't too much
> "stuff happening" between clone()/vfork() and exec() ?
>
> Maybe, if this question isn't resolved (or resolvable) soon
> then should we go ahead with a Solaris only fix?
>
> - Michael.
>


From dl at cs.oswego.edu  Thu Jul  2 14:09:10 2009
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 2 Jul 2009 10:09:10 -0400 (EDT)
Subject: Faster HashMap implementation
In-Reply-To: <f813797e0907010550v5c65c2fdvabab7575f01092b6@mail.gmail.com>
References: <f813797e0906031621l650feb9erd313d6a3872a2941@mail.gmail.com>
	<4A2D3729.3040904@cs.oswego.edu>
	<f813797e0906080959p65f04f94t170249f285e55597@mail.gmail.com>
	<4A2E5109.4050804@cs.oswego.edu>
	<f813797e0906090743oca8faf7he2c066b125c190ef@mail.gmail.com>
	<4A40FD16.6040503@cs.oswego.edu>
	<f813797e0906262054n56d251b7w5fbf4e163b565a8a@mail.gmail.com>
	<4A4A8D00.8000506@cs.oswego.edu>
	<f813797e0907010550v5c65c2fdvabab7575f01092b6@mail.gmail.com>
Message-ID: <5429.69.38.226.2.1246543750.squirrel@altair.cs.oswego.edu>

> Doug,
>
> Checking key reference equality before hashcode looks like a big win.

This effect is somewhat stronger in tests that keep looking for ==
keys, but in general, successful gets are usually for identical
keys. Except for autoboxed Integers etc.

(Aside: one way to deal with fact that we can better handle
autoboxed cases if we know them up frot would be to create
a CheckedHashMap class (in the spirit of Collections.checkedMap
and use specialized forms for Class agurments corresponding
to boxed types. Plus String while we are at it. Unfortunately
this does nothing for the millions of existing uses
of plain HashMap.)

>
> Have you considered using balancing tree instead of bit trie?
> This could decrease look depth from number of hash bits to log2(tree
> size).

Yes, but bitwise are generally faster on average in this usage
and worst case is around the same for large trees, which are
when they are used here.

>
> Also, there could be a sence in using adjacent table cell for key/value if
> it's
> not used. Maybe also without a hashcode check for less cache misses.
> In practice this gives ~4-5% performance for get(). In theory, when
> 70% of gets are resolved at first try, 23% on second, assuming that
> adjacent cell is empty in 50% cases, and in best case (referential
> equality)
> we'll have 1 cache miss instead of 3, thus .23*.5*(2/3) = 7.67%
> in worst case (2 cache misses instead of 4 with hashcode check) +5.75%

There is a delicate balancing act here. Decent performance of
linear probing relies on good key randomization. Otherwise it
tends to fall apart badly (and so for example the hit rate falls
much lower than 70%). One alternative that looks more
promising is to alternate linear and random probes. More on that
when I get a chance tp further flesh out.

-Doug




From mlists at juma.me.uk  Thu Jul  2 18:28:39 2009
From: mlists at juma.me.uk (Ismael Juma)
Date: Thu, 2 Jul 2009 18:28:39 +0000 (UTC)
Subject: Faster HashMap implementation
References: <f813797e0906031621l650feb9erd313d6a3872a2941@mail.gmail.com>
	<4A2D3729.3040904@cs.oswego.edu>
	<f813797e0906080959p65f04f94t170249f285e55597@mail.gmail.com>
	<4A2E5109.4050804@cs.oswego.edu>
	<f813797e0906090743oca8faf7he2c066b125c190ef@mail.gmail.com>
	<4A40FD16.6040503@cs.oswego.edu>
	<f813797e0906262054n56d251b7w5fbf4e163b565a8a@mail.gmail.com>
	<4A4A8D00.8000506@cs.oswego.edu>
	<f813797e0907010550v5c65c2fdvabab7575f01092b6@mail.gmail.com>
	<5429.69.38.226.2.1246543750.squirrel@altair.cs.oswego.edu>
Message-ID: <loom.20090702T181948-756@post.gmane.org>

Hi Doug,

In a previous message you said:

"There are a few remaining things to consider
before taking this too seriously as a replacement.
I'll be out for 10 days starting tomorrow so probably
won't get a chance to do so soon."

I now understand the secret behind your productivity levels... somehow 10 days
for you is the same as 2 days for the rest of us. :)

More seriously, it would be great to have a HashMap that takes less memory and
performs as well or better so I am following this with interest. If things work
out, I'd be interested in borrowing the ideas for Scala's mutable HashMap (an
additional thing to take into account there is the ongoing specialization work).

Best,
Ismael



From xuelei.fan at sun.com  Fri Jul  3 03:25:21 2009
From: xuelei.fan at sun.com (xuelei.fan at sun.com)
Date: Fri, 03 Jul 2009 03:25:21 +0000
Subject: hg: jdk7/tl/jdk: 6853793: OutOfMemoryError in
	sun.security.provider.certpath.OCSPChecker.check
Message-ID: <20090703032550.63956E9BD@hg.openjdk.java.net>

Changeset: c2baa2f0415e
Author:    xuelei
Date:      2009-07-03 11:13 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c2baa2f0415e

6853793: OutOfMemoryError in sun.security.provider.certpath.OCSPChecker.check
Summary: allocate memory dynamically, keep reading until EOF.
Reviewed-by: weijun

! src/share/classes/sun/security/provider/certpath/OCSPChecker.java
! src/share/classes/sun/security/timestamp/HttpTimestamper.java



From martinrb at google.com  Fri Jul  3 14:32:23 2009
From: martinrb at google.com (martinrb at google.com)
Date: Fri, 03 Jul 2009 14:32:23 +0000
Subject: hg: jdk7/tl/jdk: 6857287: (file) Clarifications for symbolic link
	related javadoc
Message-ID: <20090703143302.874DDEA8B@hg.openjdk.java.net>

Changeset: 803db6c94a3b
Author:    martin
Date:      2009-07-03 07:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/803db6c94a3b

6857287: (file) Clarifications for symbolic link related javadoc
Summary: Fix up jsr203 file javadoc related to symbolic links
Reviewed-by: alanb

! src/share/classes/java/nio/file/LinkPermission.java
! src/share/classes/java/nio/file/NotLinkException.java
! src/share/classes/java/nio/file/Path.java
! src/share/classes/java/nio/file/SecureDirectoryStream.java
! src/share/classes/java/nio/file/attribute/Attributes.java
! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java



From dl at cs.oswego.edu  Sat Jul  4 07:00:39 2009
From: dl at cs.oswego.edu (Doug Lea)
Date: Sat, 4 Jul 2009 03:00:39 -0400 (EDT)
Subject: Faster HashMap implementation
In-Reply-To: <loom.20090702T181948-756@post.gmane.org>
References: <f813797e0906031621l650feb9erd313d6a3872a2941@mail.gmail.com>
	<4A2D3729.3040904@cs.oswego.edu>
	<f813797e0906080959p65f04f94t170249f285e55597@mail.gmail.com>
	<4A2E5109.4050804@cs.oswego.edu>
	<f813797e0906090743oca8faf7he2c066b125c190ef@mail.gmail.com>
	<4A40FD16.6040503@cs.oswego.edu>
	<f813797e0906262054n56d251b7w5fbf4e163b565a8a@mail.gmail.com>
	<4A4A8D00.8000506@cs.oswego.edu>
	<f813797e0907010550v5c65c2fdvabab7575f01092b6@mail.gmail.com>
	<5429.69.38.226.2.1246543750.squirrel@altair.cs.oswego.edu>
	<loom.20090702T181948-756@post.gmane.org>
Message-ID: <58327.89.96.170.50.1246690839.squirrel@altair.cs.oswego.edu>

>  somehow 10
> days
> for you is the same as 2 days for the rest of us. :)

(Well, I was unexpectedly stranded at JFK for 20 hrs, but
now really am in sporadic e-mail mode for 9 days.)

>
> More seriously, it would be great to have a HashMap that takes less memory
> and
> performs as well or better so I am following this with interest. If things
> work
> out, I'd be interested in borrowing the ideas for Scala's mutable HashMap
> (an
> additional thing to take into account there is the ongoing specialization
> work).
>

Specialization should help common cases. the three of :
Strings, Integer/Long, and identity-based (no equals/hashCode override)
not only seem to together account for up to 80% of usages,
but all three would allow more space-conserving and faster solutions
in part because there is no reason to store hash codes for them.

Maybe it is worth introducing java.util.CheckedHashMap (as in my
previous note) as a relatively simple way for people to
get this better performance in Java at the expense of
having to consciously change existing constructions of
HashMap. This would at least avoid the need for people to
use non-JDK alterantives in these cases. On the other hand,
the very low relative occurrence of programs using
IdentiyHashMap in the many cases it applies suggests that
people won't often enough use these when they should?


-Doug






From forax at univ-mlv.fr  Sat Jul  4 14:47:17 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Sat, 04 Jul 2009 16:47:17 +0200
Subject: Faster HashMap implementation
In-Reply-To: <58327.89.96.170.50.1246690839.squirrel@altair.cs.oswego.edu>
References: <f813797e0906031621l650feb9erd313d6a3872a2941@mail.gmail.com>	<4A2D3729.3040904@cs.oswego.edu>	<f813797e0906080959p65f04f94t170249f285e55597@mail.gmail.com>	<4A2E5109.4050804@cs.oswego.edu>	<f813797e0906090743oca8faf7he2c066b125c190ef@mail.gmail.com>	<4A40FD16.6040503@cs.oswego.edu>	<f813797e0906262054n56d251b7w5fbf4e163b565a8a@mail.gmail.com>	<4A4A8D00.8000506@cs.oswego.edu>	<f813797e0907010550v5c65c2fdvabab7575f01092b6@mail.gmail.com>	<5429.69.38.226.2.1246543750.squirrel@altair.cs.oswego.edu>	<loom.20090702T181948-756@post.gmane.org>
	<58327.89.96.170.50.1246690839.squirrel@altair.cs.oswego.edu>
Message-ID: <4A4F6B75.607@univ-mlv.fr>

Doug Lea a ?crit :
>>  somehow 10
>> days
>> for you is the same as 2 days for the rest of us. :)
>>     
>
> (Well, I was unexpectedly stranded at JFK for 20 hrs, but
> now really am in sporadic e-mail mode for 9 days.)
>
>   
>> More seriously, it would be great to have a HashMap that takes less memory
>> and
>> performs as well or better so I am following this with interest. If things
>> work
>> out, I'd be interested in borrowing the ideas for Scala's mutable HashMap
>> (an
>> additional thing to take into account there is the ongoing specialization
>> work).
>>
>>     
>
> Specialization should help common cases. the three of :
> Strings, Integer/Long, and identity-based (no equals/hashCode override)
> not only seem to together account for up to 80% of usages,
> but all three would allow more space-conserving and faster solutions
> in part because there is no reason to store hash codes for them.
>
> Maybe it is worth introducing java.util.CheckedHashMap (as in my
> previous note) as a relatively simple way for people to
> get this better performance in Java at the expense of
> having to consciously change existing constructions of
> HashMap. 

The other solution is to teach the VM.
We can image something that based on type profiling select
the optimized Map implementation.
I know that there is already something like that in the hotspot sources
but I haven't take a look to this part of the VM so I don't know
exactly what is done.

> This would at least avoid the need for people to
> use non-JDK alterantives in these cases. On the other hand,
> the very low relative occurrence of programs using
> IdentiyHashMap in the many cases it applies suggests that
> people won't often enough use these when they should?
>
>
> -Doug
>
>   
R?mi


From tim.bell at sun.com  Sat Jul  4 17:40:27 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sat, 04 Jul 2009 17:40:27 +0000
Subject: hg: jdk7/tl: 4 new changesets
Message-ID: <20090704174028.42A17EB0A@hg.openjdk.java.net>

Changeset: 60b818e5e4f9
Author:    andrew
Date:      2009-06-17 20:53 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/60b818e5e4f9

6851515: awt_p.h incorporates a chunk of the XRender header
Summary: Use XRender header directly rather than copying chunks locally
Reviewed-by: anthony, ohair

! README-builds.html

Changeset: c7ed15ab92ce
Author:    yan
Date:      2009-06-23 23:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/c7ed15ab92ce

Merge


Changeset: 57f7e028c7ad
Author:    xdono
Date:      2009-06-25 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/57f7e028c7ad

Added tag jdk7-b62 for changeset c7ed15ab92ce

! .hgtags

Changeset: 9849536536d2
Author:    xdono
Date:      2009-07-02 11:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/9849536536d2

Added tag jdk7-b63 for changeset 57f7e028c7ad

! .hgtags



From tim.bell at sun.com  Sat Jul  4 17:46:19 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sat, 04 Jul 2009 17:46:19 +0000
Subject: hg: jdk7/tl/corba: 2 new changesets
Message-ID: <20090704174621.DA188EB0F@hg.openjdk.java.net>

Changeset: d20e45cd539f
Author:    xdono
Date:      2009-06-25 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/d20e45cd539f

Added tag jdk7-b62 for changeset 65b66117dbd7

! .hgtags

Changeset: b3ad991d9534
Author:    xdono
Date:      2009-07-02 11:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/b3ad991d9534

Added tag jdk7-b63 for changeset d20e45cd539f

! .hgtags



From tim.bell at sun.com  Sat Jul  4 17:54:50 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sat, 04 Jul 2009 17:54:50 +0000
Subject: hg: jdk7/tl/hotspot: 11 new changesets
Message-ID: <20090704175515.ACF89EB14@hg.openjdk.java.net>

Changeset: 8754a3c37762
Author:    xdono
Date:      2009-06-25 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8754a3c37762

Added tag jdk7-b62 for changeset a88386380bda

! .hgtags

Changeset: 821269eca479
Author:    ysr
Date:      2009-06-11 12:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/821269eca479

6820167: GCALotAtAllSafepoints + FullGCALot(ScavengeALot) options crash JVM
Summary: Short-circuit gc-a-lot attempts by non-JavaThreads; SkipGCALot c'tor to elide re-entrant gc-a-lot attempts.
Reviewed-by: apetrusenko, jcoomes, jmasa, kamg

! src/share/vm/memory/gcLocker.hpp
! src/share/vm/runtime/interfaceSupport.cpp
! src/share/vm/runtime/thread.cpp
! src/share/vm/runtime/thread.hpp
! src/share/vm/runtime/vmThread.cpp

Changeset: d44bdab1c03d
Author:    johnc
Date:      2009-06-11 17:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d44bdab1c03d

6843694: G1: assert(index < _vs.committed_size(),"bad index"), g1BlockOffsetTable.inline.hpp:55
Summary: For heaps larger than 32Gb, the number of heap regions overflows the data type used to hold the region index in the SparsePRT structure. Changed the region indexes, card indexes, and RSet hash table buckets to ints and added some size overflow guarantees.
Reviewed-by: ysr, tonyp

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.cpp
! src/share/vm/gc_implementation/g1/sparsePRT.hpp
! src/share/vm/gc_implementation/includeDB_gc_g1

Changeset: 353ba4575581
Author:    jcoomes
Date:      2009-06-07 22:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/353ba4575581

6814552: par compact - some compilers fail to optimize bitmap code
Reviewed-by: tonyp, iveresov, jmasa, ysr

! src/share/vm/gc_implementation/parallelScavenge/parMarkBitMap.hpp

Changeset: 6e2afda171db
Author:    jcoomes
Date:      2009-06-11 13:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6e2afda171db

6849716: BitMap - performance regression introduced with G1
Summary: make verification code visible only in debug builds
Reviewed-by: iveresov, ysr, johnc, apetrusenko, tonyp

! src/share/vm/includeDB_compiler1
! src/share/vm/utilities/bitMap.cpp
! src/share/vm/utilities/bitMap.hpp
! src/share/vm/utilities/bitMap.inline.hpp
! src/share/vm/utilities/macros.hpp

Changeset: 3104f76478ee
Author:    jmasa
Date:      2009-06-18 12:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3104f76478ee

Merge


Changeset: 830ca2573896
Author:    tonyp
Date:      2009-06-12 16:20 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/830ca2573896

6850846: G1: extend G1 marking verification
Summary: extend G1 marking verification to use either the "prev" or "next" marking information, as appropriate.
Reviewed-by: johnc, ysr

! src/share/vm/gc_implementation/g1/concurrentMark.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/gc_implementation/g1/heapRegion.hpp

Changeset: 85d0690f7d12
Author:    jmasa
Date:      2009-06-19 07:33 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/85d0690f7d12

Merge


Changeset: f9c95d5dc41f
Author:    trims
Date:      2009-06-25 22:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f9c95d5dc41f

Merge


Changeset: 32c83fb84370
Author:    trims
Date:      2009-06-30 10:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/32c83fb84370

6856257: Bump the HS16 build number to 05
Summary: Update the HS16 build number to 05
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: ba36394eb84b
Author:    xdono
Date:      2009-07-02 11:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ba36394eb84b

Added tag jdk7-b63 for changeset 32c83fb84370

! .hgtags



From tim.bell at sun.com  Sat Jul  4 18:07:05 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sat, 04 Jul 2009 18:07:05 +0000
Subject: hg: jdk7/tl/jaxp: 2 new changesets
Message-ID: <20090704180709.BD1E0EB1B@hg.openjdk.java.net>

Changeset: ae449e9c04c1
Author:    xdono
Date:      2009-06-25 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/ae449e9c04c1

Added tag jdk7-b62 for changeset a97dd57a6260

! .hgtags

Changeset: a10eec7a1edf
Author:    xdono
Date:      2009-07-02 11:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/a10eec7a1edf

Added tag jdk7-b63 for changeset ae449e9c04c1

! .hgtags



From tim.bell at sun.com  Sat Jul  4 18:13:46 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sat, 04 Jul 2009 18:13:46 +0000
Subject: hg: jdk7/tl/jaxws: 2 new changesets
Message-ID: <20090704181349.E5545EB20@hg.openjdk.java.net>

Changeset: b8a6e883c0a6
Author:    xdono
Date:      2009-06-25 12:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/b8a6e883c0a6

Added tag jdk7-b62 for changeset 75c801c13ea1

! .hgtags

Changeset: aaa25dfd3de6
Author:    xdono
Date:      2009-07-02 11:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/aaa25dfd3de6

Added tag jdk7-b63 for changeset b8a6e883c0a6

! .hgtags



From tim.bell at sun.com  Sat Jul  4 18:22:45 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sat, 04 Jul 2009 18:22:45 +0000
Subject: hg: jdk7/tl/jdk: 32 new changesets
Message-ID: <20090704183119.4DF2DEB25@hg.openjdk.java.net>

Changeset: 6f1f159aed75
Author:    yan
Date:      2009-06-03 17:41 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6f1f159aed75

6839645: Swing application prints message in Control Panel if language is changed
Summary: just remove debug printout from production builds; ignore multicharacter-generating keys
Reviewed-by: uta

! src/windows/native/sun/windows/awt_Component.cpp

Changeset: a3f970a8600b
Author:    anthony
Date:      2009-06-04 15:18 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a3f970a8600b

6832386: Fix JTreg test: java/awt/Graphics/DrawImageBG/SystemBgColorTest.java
Summary: Removed unneeded System.exit(0) call.
Reviewed-by: art, ohair, anthony
Contributed-by: Omair Majid <omajid at redhat.com>

! test/java/awt/Graphics/DrawImageBG/SystemBgColorTest.java

Changeset: 7289003cd1c9
Author:    dcherepanov
Date:      2009-06-05 17:30 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7289003cd1c9

6829180: Removing focused component from a window causes a JVM crash for JDK7b50+ on WinXP/Vista
Summary: access pData on the toolkit thread
Reviewed-by: art, anthony, naoto

! src/windows/native/sun/windows/awt_Component.cpp
! src/windows/native/sun/windows/awt_InputMethod.cpp
! src/windows/native/sun/windows/awt_Toolkit.cpp
! src/windows/native/sun/windows/awt_Toolkit.h
! src/windows/native/sun/windows/awtmsg.h

Changeset: 70654407b626
Author:    dcherepanov
Date:      2009-06-15 11:15 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/70654407b626

6847584: closed/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html fails
Reviewed-by: anthony

+ test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.html
! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java

Changeset: 0e441c781cdc
Author:    yan
Date:      2009-06-16 00:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0e441c781cdc

Merge

- src/share/native/sun/java2d/pipe/RenderBuffer.c

Changeset: 2a526ccd12e8
Author:    andrew
Date:      2009-06-17 21:13 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2a526ccd12e8

6851515: awt_p.h incorporates a chunk of the XRender header
Summary: Use XRender header directly rather than copying chunks locally
Reviewed-by: anthony, ohair

! src/solaris/native/sun/awt/awt_GraphicsEnv.c
! src/solaris/native/sun/awt/awt_p.h

Changeset: 1bbbd0ef5d04
Author:    peytoia
Date:      2009-06-13 06:43 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1bbbd0ef5d04

6850113: Bidi class needs to be updated to support Unicode 5.1
Reviewed-by: okutsu

! make/java/text/FILES_java.gmk
! make/sun/font/FILES_c.gmk
! make/sun/font/Makefile
! make/sun/font/mapfile-vers
! make/sun/font/mapfile-vers.openjdk
! src/share/classes/java/text/Bidi.java
+ src/share/classes/sun/text/bidi/BidiBase.java
+ src/share/classes/sun/text/bidi/BidiLine.java
+ src/share/classes/sun/text/bidi/BidiRun.java
! src/share/classes/sun/text/normalizer/UCharacter.java
- src/share/native/sun/font/bidi/cmemory.h
- src/share/native/sun/font/bidi/jbidi.c
- src/share/native/sun/font/bidi/jbidi.h
- src/share/native/sun/font/bidi/ubidi.c
- src/share/native/sun/font/bidi/ubidi.h
- src/share/native/sun/font/bidi/ubidiimp.h
- src/share/native/sun/font/bidi/ubidiln.c
- src/share/native/sun/font/bidi/uchardir.c
- src/share/native/sun/font/bidi/uchardir.h
- src/share/native/sun/font/bidi/utypes.h
! src/share/native/sun/font/layout/LETypes.h
! test/java/text/Bidi/BidiBug.java
+ test/java/text/Bidi/BidiConformance.java
! test/java/text/Bidi/BidiEmbeddingTest.java
+ test/java/text/Bidi/Bug6850113.java

Changeset: 45316d7cc9dc
Author:    yan
Date:      2009-06-17 23:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/45316d7cc9dc

Merge

- src/share/native/sun/font/bidi/cmemory.h
- src/share/native/sun/font/bidi/jbidi.c
- src/share/native/sun/font/bidi/jbidi.h
- src/share/native/sun/font/bidi/ubidi.c
- src/share/native/sun/font/bidi/ubidi.h
- src/share/native/sun/font/bidi/ubidiimp.h
- src/share/native/sun/font/bidi/ubidiln.c
- src/share/native/sun/font/bidi/uchardir.c
- src/share/native/sun/font/bidi/uchardir.h
- src/share/native/sun/font/bidi/utypes.h

Changeset: 12e11fab9a83
Author:    yan
Date:      2009-06-23 23:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/12e11fab9a83

Merge

- src/share/native/sun/font/bidi/cmemory.h
- src/share/native/sun/font/bidi/jbidi.c
- src/share/native/sun/font/bidi/jbidi.h
- src/share/native/sun/font/bidi/ubidi.c
- src/share/native/sun/font/bidi/ubidi.h
- src/share/native/sun/font/bidi/ubidiimp.h
- src/share/native/sun/font/bidi/ubidiln.c
- src/share/native/sun/font/bidi/uchardir.c
- src/share/native/sun/font/bidi/uchardir.h
- src/share/native/sun/font/bidi/utypes.h

Changeset: 8905d218cd0d
Author:    xdono
Date:      2009-06-25 12:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8905d218cd0d

Added tag jdk7-b62 for changeset 12e11fab9a83

! .hgtags

Changeset: 9f243df213fa
Author:    tbell
Date:      2009-06-26 10:25 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9f243df213fa

Merge

- src/share/classes/sun/io/ByteToCharMS932DB.java
- src/share/classes/sun/io/CharToByteMS932DB.java
- src/share/classes/sun/nio/cs/ext/EUC_CN.java
- src/share/classes/sun/nio/cs/ext/EUC_KR.java
- src/share/classes/sun/nio/cs/ext/GBK.java
- src/share/classes/sun/nio/cs/ext/Johab.java
- src/share/classes/sun/nio/cs/ext/MS932.java
- src/share/classes/sun/nio/cs/ext/MS932DB.java
- src/share/classes/sun/nio/cs/ext/MS936.java
- src/share/classes/sun/nio/cs/ext/MS949.java
- src/share/classes/sun/nio/cs/ext/MS950.java

Changeset: bd4f0613dd92
Author:    tbell
Date:      2009-06-28 00:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bd4f0613dd92

Merge


Changeset: 35b19adcb215
Author:    tbell
Date:      2009-06-28 23:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/35b19adcb215

Merge

- src/share/classes/java/nio/file/DirectoryStreamFilters.java
- src/share/classes/java/nio/file/FileAction.java
- src/share/classes/java/nio/file/spi/AbstractPath.java
- src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java
- src/share/classes/sun/nio/fs/MimeType.java
- test/java/nio/file/DirectoryStream/Filters.java
- test/java/nio/file/Files/content_type.sh
- test/java/nio/file/Path/temporary_files.sh
- test/java/nio/file/attribute/Attributes/Basic.java

Changeset: cb20a8a1f22f
Author:    tbell
Date:      2009-06-29 17:40 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cb20a8a1f22f

Merge


Changeset: 861f23119072
Author:    tbell
Date:      2009-06-29 23:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/861f23119072

Merge


Changeset: 9cf4ef04d9a7
Author:    prr
Date:      2009-05-06 14:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9cf4ef04d9a7

6806822: Font.getFontName() is slow in Java5 and 6
Reviewed-by: igor, jgodinez

! src/share/classes/sun/font/TrueTypeFont.java

Changeset: ec0a8acd4737
Author:    jgodinez
Date:      2009-05-14 09:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ec0a8acd4737

Merge


Changeset: fb03586d68b6
Author:    jgodinez
Date:      2009-05-21 09:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fb03586d68b6

6829659: Circle is rendered in C shape
Reviewed-by: campbell, flar
Contributed-by: Google <yamauchi at google.com>

! src/share/classes/sun/java2d/pisces/PiscesCache.java
+ test/sun/pisces/ScaleTest.java

Changeset: 907324eb3e64
Author:    bae
Date:      2009-05-23 08:35 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/907324eb3e64

4893408: JPEGReader throws IllegalArgException when setting the destination to BYTE_GRAY
Reviewed-by: igor, prr

! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java
! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGMetadata.java
! src/share/classes/java/awt/color/ICC_Profile.java
! src/share/native/sun/awt/image/jpeg/imageioJPEG.c
+ test/javax/imageio/plugins/jpeg/ReadAsGrayTest.java

Changeset: b92e3fbbcb63
Author:    jgodinez
Date:      2009-06-08 13:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b92e3fbbcb63

Merge


Changeset: 378feb59435b
Author:    bae
Date:      2009-06-11 13:47 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/378feb59435b

6296893: BMP Writer handles TopDown property incorrectly for some of the compression types
Reviewed-by: igor, prr

! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java
+ test/javax/imageio/plugins/bmp/TopDownTest.java

Changeset: e138ae33b128
Author:    bae
Date:      2009-06-11 14:22 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e138ae33b128

5101862: WBMP Image reader tries to load Quicktime MOV files
Reviewed-by: igor, prr

! src/share/classes/com/sun/imageio/plugins/common/ReaderUtil.java
! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReader.java
! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java
+ test/javax/imageio/plugins/wbmp/CanDecodeTest.java

Changeset: 0ce29cbeb6a9
Author:    bae
Date:      2009-06-15 14:49 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0ce29cbeb6a9

6829549: JVM crash on certain images
Reviewed-by: igor, prr

! src/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageReader.java

Changeset: 5896dcd01fe3
Author:    bae
Date:      2009-06-15 17:19 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5896dcd01fe3

6684104: Applets fails to launch using ImageIO if .java.policy with File permissions present on the system
Reviewed-by: igor, prr

! src/share/classes/javax/imageio/ImageIO.java
+ test/javax/imageio/CachePremissionsTest/CachePermissionsTest.java
+ test/javax/imageio/CachePremissionsTest/rw.policy
+ test/javax/imageio/CachePremissionsTest/rwd.policy
+ test/javax/imageio/CachePremissionsTest/w.policy

Changeset: 956715ded919
Author:    jgodinez
Date:      2009-06-15 09:59 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/956715ded919

Merge


Changeset: 70903e2c39e3
Author:    jgodinez
Date:      2009-06-22 09:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/70903e2c39e3

6850398: Allow GraphicsEnvironment to be loaded by system classloader  (edit)
Reviewed-by: campbell, prr

! src/share/classes/java/awt/GraphicsEnvironment.java

Changeset: fafa991c27ac
Author:    prr
Date:      2009-06-22 14:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fafa991c27ac

6853617: race condition in java.awt.Font.getAttributes() (private method)
Reviewed-by: igor, jgodinez

! src/share/classes/java/awt/Font.java

Changeset: 2886eb650801
Author:    jgodinez
Date:      2009-06-24 11:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2886eb650801

Merge

- src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/IBM1381.java
- src/share/classes/sun/nio/cs/ext/IBM1383.java
- src/share/classes/sun/nio/cs/ext/IBM930.java
- src/share/classes/sun/nio/cs/ext/IBM933.java
- src/share/classes/sun/nio/cs/ext/IBM935.java
- src/share/classes/sun/nio/cs/ext/IBM937.java
- src/share/classes/sun/nio/cs/ext/IBM939.java
- src/share/classes/sun/nio/cs/ext/IBM942.java
- src/share/classes/sun/nio/cs/ext/IBM943.java
- src/share/classes/sun/nio/cs/ext/IBM948.java
- src/share/classes/sun/nio/cs/ext/IBM949.java
- src/share/classes/sun/nio/cs/ext/IBM950.java
- src/share/classes/sun/nio/cs/ext/IBM970.java
- src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java
- src/share/native/sun/font/bidi/cmemory.h
- src/share/native/sun/font/bidi/jbidi.c
- src/share/native/sun/font/bidi/jbidi.h
- src/share/native/sun/font/bidi/ubidi.c
- src/share/native/sun/font/bidi/ubidi.h
- src/share/native/sun/font/bidi/ubidiimp.h
- src/share/native/sun/font/bidi/ubidiln.c
- src/share/native/sun/font/bidi/uchardir.c
- src/share/native/sun/font/bidi/uchardir.h
- src/share/native/sun/font/bidi/utypes.h

Changeset: 2ed6ed6b5bfc
Author:    jgodinez
Date:      2009-06-29 14:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2ed6ed6b5bfc

Merge


Changeset: 120df7f49509
Author:    xdono
Date:      2009-07-02 11:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/120df7f49509

Added tag jdk7-b63 for changeset 2ed6ed6b5bfc

! .hgtags

Changeset: 4e4ff42f3140
Author:    tbell
Date:      2009-07-03 09:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4e4ff42f3140

Merge


Changeset: 75459b125461
Author:    tbell
Date:      2009-07-03 16:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/75459b125461

Merge




From tim.bell at sun.com  Sat Jul  4 18:49:08 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Sat, 04 Jul 2009 18:49:08 +0000
Subject: hg: jdk7/tl/langtools: 6 new changesets
Message-ID: <20090704184922.09B43EB31@hg.openjdk.java.net>

Changeset: 5c2c81120555
Author:    xdono
Date:      2009-06-25 12:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5c2c81120555

Added tag jdk7-b62 for changeset 6855e5aa3348

! .hgtags

Changeset: e71fd3fcebf5
Author:    tbell
Date:      2009-06-26 10:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e71fd3fcebf5

Merge


Changeset: c391a167ac57
Author:    tbell
Date:      2009-06-28 00:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c391a167ac57

Merge


Changeset: ec1acd3af057
Author:    tbell
Date:      2009-06-29 23:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ec1acd3af057

Merge


Changeset: 619c768ad104
Author:    xdono
Date:      2009-07-02 11:11 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/619c768ad104

Added tag jdk7-b63 for changeset 5c2c81120555

! .hgtags

Changeset: 24374861f91e
Author:    tbell
Date:      2009-07-03 09:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/24374861f91e

Merge




From ilgo711 at gmail.com  Sun Jul  5 06:23:56 2009
From: ilgo711 at gmail.com (ilgo)
Date: Sun, 5 Jul 2009 15:23:56 +0900
Subject: 6520207: Dollar/UnixDollar bad behavior shouldn't match twice in "\n"
Message-ID: <45cbc65d0907042323y351fa686o2b52b351fe8ffc4f@mail.gmail.com>

Hi there,

i am new here....so i need to learn how to communicate properly...

i have been working on java.util.regex bug no.
6520207<http://bugs.sun.com/view_bug.do?bug_id=6520207>. I found a two
line fix and all the tests that come with the openJDK source
belonging to the regex package seem to work fine.

The change i implemented is the following:

Pattern.java at line 3374 inserting

* 3374:   if (matcher.first == endIndex && seq.charAt(i - 1) == '\n')
 3375:       return false;*

Reason:
the "$" pattern matches "a\nb\nc\n" twice. At the end of the last
line-terminator as well as at the end of input.
Since the second match is matching only the end of input and no real
characters, i first check if the new match starts at the end of input, and
since this bug only occurs with a '\n' as the last character in the string
to be matched, i check for that too. If this is the case then we dont want
to match anymore, so return false.

Regards ilgo

PS: how do i go on from here...?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090705/0492f99a/attachment.html>

From jean-christophe.collet at sun.com  Mon Jul  6 14:12:04 2009
From: jean-christophe.collet at sun.com (jean-christophe.collet at sun.com)
Date: Mon, 06 Jul 2009 14:12:04 +0000
Subject: hg: jdk7/tl/jdk: 6856856: NPE in HTTP protocol handler logging
Message-ID: <20090706141244.E444BEBF1@hg.openjdk.java.net>

Changeset: fa488e4ff685
Author:    jccollet
Date:      2009-07-06 15:13 +0200
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fa488e4ff685

6856856: NPE in HTTP protocol handler logging
Summary: Fixed the NPE and Moved the java.util.logging dependency to a single class and used reflection to make it a soft one.
Reviewed-by: chegar

! src/share/classes/sun/net/www/http/HttpCapture.java
! src/share/classes/sun/net/www/http/HttpClient.java
! src/share/classes/sun/net/www/protocol/http/HttpLogFormatter.java
! src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java



From martinrb at google.com  Mon Jul  6 19:06:20 2009
From: martinrb at google.com (martinrb at google.com)
Date: Mon, 06 Jul 2009 19:06:20 +0000
Subject: hg: jdk7/tl/jdk: 6854795: Miscellaneous improvements to "jar"
Message-ID: <20090706190637.ED1DDEC50@hg.openjdk.java.net>

Changeset: 0cabe1192c8b
Author:    martin
Date:      2009-07-06 11:30 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0cabe1192c8b

6854795: Miscellaneous improvements to "jar"
Summary: cleanup of jar/Main.java (Initial patch by tobyr at google.com, additional review by jeremymanson at google.com, ulf.zibis at gmx.de)
Reviewed-by: sherman, alanb

! src/share/classes/sun/tools/jar/Main.java
! test/tools/jar/index/MetaInf.java



From martinrb at google.com  Mon Jul  6 20:58:40 2009
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 6 Jul 2009 13:58:40 -0700
Subject: Miscellaneous improvements to "jar".
In-Reply-To: <4A48555E.10900@sun.com>
References: <1ccfd1c10906241934i21247553w685cf0b0b4cbd7b2@mail.gmail.com>
	<1ccfd1c10906251200n3bd78beek400abb51adcece40@mail.gmail.com>
	<1ccfd1c10906251757y72ccaca1l289dfc79f18b002c@mail.gmail.com>
	<4A450656.7070008@sun.com>
	<1ccfd1c10906270956g6c2f6208ne31f511ebcfaa41a@mail.gmail.com>
	<4A48555E.10900@sun.com>
Message-ID: <1ccfd1c10907061358w4815ce4by4145522e1c12edee@mail.gmail.com>

I will atone for my use of nio2
by providing the backport to openjdk6.

6854795: Miscellaneous improvements to "jar"
6834805: Improve jar -C performance
6332094: "jar t" and "jar x" should use ZipFile, not ZipInputStream
6496274: jar seems to use more CPU than it should
Summary: backport jdk7 jar command (remove use of nio2)

Assuming darcy and sherman agree,
I will commit this to openjdk6.

http://cr.openjdk.java.net/~martin/webrevs/openjdk6/jar-misc-6/

Martin

On Sun, Jun 28, 2009 at 22:47, Xueming Shen<Xueming.Shen at sun.com> wrote:
> (2)nio2 APIs are good, but now I can't not just copy/paste the jar Main to
> 6.x:-)


From martinrb at google.com  Mon Jul  6 21:17:48 2009
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 6 Jul 2009 14:17:48 -0700
Subject: -classpath @FILE
Message-ID: <1ccfd1c10907061417s6e3545d1j8cf05a0f108be01d@mail.gmail.com>

Hi launcher team,

We have a local mod to openjdk's launcher here at Google
that we would be willing to send upstream.
We were hitting the 128kb command line arg limit
(that is, the Linux limit on the size of *one* argument,
not the entire command line) and made the simple expedient
of allowing the classpath to be specified via a file,
using the familiar
-cp @FILE
syntax.

It's hard to create a uniform support for @FILE
across all jdk commands, because the jar and javac
commands already do their own @FILE parsing.
So although -cp @FILE is a bit of a hack,
it is useful enough that it probably should be part of the jdk.
Remember that jdk engineers tend not to experience "jar hell"
themselves.

Martin


From i30817 at gmail.com  Mon Jul  6 21:35:04 2009
From: i30817 at gmail.com (Paulo Levi)
Date: Mon, 6 Jul 2009 22:35:04 +0100
Subject: Is Closeable going to get a super-interface that throws Exception
Message-ID: <212322090907061435p3ef1eb20p5a245bbe042a9516@mail.gmail.com>

Instead of IOException? I understand that this is fundamental to the using
proposal, but something similar is possible with try{} finally[} if only
this interface is introduced and used.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090706/7fafa3d0/attachment.html>

From neal at gafter.com  Mon Jul  6 21:43:12 2009
From: neal at gafter.com (Neal Gafter)
Date: Mon, 6 Jul 2009 14:43:12 -0700
Subject: Is Closeable going to get a super-interface that throws Exception
In-Reply-To: <212322090907061435p3ef1eb20p5a245bbe042a9516@mail.gmail.com>
References: <212322090907061435p3ef1eb20p5a245bbe042a9516@mail.gmail.com>
Message-ID: <15e8b9d20907061443k7459dbd0occa2fe4ca2f39c18@mail.gmail.com>

That question is being considered by project Coin as part of the ARM proposal.

On Mon, Jul 6, 2009 at 2:35 PM, Paulo Levi<i30817 at gmail.com> wrote:
> Instead of IOException? I understand that this is fundamental to the using
> proposal, but something similar is possible with try{} finally[} if only
> this interface is introduced and used.
>


From Kumar.Srinivasan at Sun.COM  Mon Jul  6 22:08:56 2009
From: Kumar.Srinivasan at Sun.COM (Kumar Srinivasan)
Date: Mon, 06 Jul 2009 15:08:56 -0700
Subject: -classpath @FILE
In-Reply-To: <1ccfd1c10907061417s6e3545d1j8cf05a0f108be01d@mail.gmail.com>
References: <1ccfd1c10907061417s6e3545d1j8cf05a0f108be01d@mail.gmail.com>
Message-ID: <4A5275F8.60307@Sun.COM>

Hi Martin,

I take it you want me to integrate this after due diligence ?

I can take a look at it, as a submission, but I can't promise when I will
be able to look into getting it into openjdk as my priorities are focused
elsewhere at this time.

Thanks
Kumar

> Hi launcher team,
>
> We have a local mod to openjdk's launcher here at Google
> that we would be willing to send upstream.
> We were hitting the 128kb command line arg limit
> (that is, the Linux limit on the size of *one* argument,
> not the entire command line) and made the simple expedient
> of allowing the classpath to be specified via a file,
> using the familiar
> -cp @FILE
> syntax.
>
> It's hard to create a uniform support for @FILE
> across all jdk commands, because the jar and javac
> commands already do their own @FILE parsing.
> So although -cp @FILE is a bit of a hack,
> it is useful enough that it probably should be part of the jdk.
> Remember that jdk engineers tend not to experience "jar hell"
> themselves.
>
> Martin
>   


-- 
Kumar Srinivasan           
Sun Microsystems, Java Software.
408-276-7586



From martinrb at google.com  Mon Jul  6 22:19:22 2009
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 6 Jul 2009 15:19:22 -0700
Subject: -classpath @FILE
In-Reply-To: <4A5275F8.60307@Sun.COM>
References: <1ccfd1c10907061417s6e3545d1j8cf05a0f108be01d@mail.gmail.com>
	<4A5275F8.60307@Sun.COM>
Message-ID: <1ccfd1c10907061519y43474f4ckc3cda4be526e0c60@mail.gmail.com>

On Mon, Jul 6, 2009 at 15:08, Kumar Srinivasan<Kumar.Srinivasan at sun.com> wrote:
> Hi Martin,
>
> I take it you want me to integrate this after due diligence ?

Yes.
We are not in any hurry to integrate it,
and we understand that there may need to be work done on
this (like generalization/doc/test work) that Google might not
want to do (or cannot, in the case of the man pages),
so this change may reasonably remain unmerged.
For the time being, it is useful for us.

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/classpath at FILE/

Please file an RFE.

Martin

> I can take a look at it, as a submission, but I can't promise when I will
> be able to look into getting it into openjdk as my priorities are focused
> elsewhere at this time.
>
> Thanks
> Kumar
>
>> Hi launcher team,
>>
>> We have a local mod to openjdk's launcher here at Google
>> that we would be willing to send upstream.
>> We were hitting the 128kb command line arg limit
>> (that is, the Linux limit on the size of *one* argument,
>> not the entire command line) and made the simple expedient
>> of allowing the classpath to be specified via a file,
>> using the familiar
>> -cp @FILE
>> syntax.
>>
>> It's hard to create a uniform support for @FILE
>> across all jdk commands, because the jar and javac
>> commands already do their own @FILE parsing.
>> So although -cp @FILE is a bit of a hack,
>> it is useful enough that it probably should be part of the jdk.
>> Remember that jdk engineers tend not to experience "jar hell"
>> themselves.
>>
>> Martin
>>
>
>
> --
> Kumar Srinivasan ? ? ? ? ? Sun Microsystems, Java Software.
> 408-276-7586
>
>


From martinrb at google.com  Mon Jul  6 23:12:03 2009
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 6 Jul 2009 16:12:03 -0700
Subject: timsort
In-Reply-To: <4A4A5961.6070201@sun.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
Message-ID: <1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>

No one actually said NO, but both Alan and Andrew strongly hinted that
a backward compatibility mode would be good.
So I kept the old implementation and allow it to be selectable
via a system property.  There's nothing more compatible than
the legacy implementation.

    /**
     * Old merge sort implementation can be selected (for
     * compatibility with broken comparators) using a system property.
     * Cannot be a static boolean in the enclosing class due to
     * circular dependencies.  To be removed in a future release.
     */
    static final class LegacyMergeSort {
        private static final boolean userRequested =
            java.security.AccessController.doPrivileged(
                new sun.security.action.GetBooleanAction(
                    "java.util.Arrays.useLegacyMergeSort")).booleanValue();
    }

The sort method bodies now look like:

        if (LegacyMergeSort.userRequested)
            legacyMergeSort(a);
        else
            ComparableTimSort.sort(a);

New webrev at:
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/

If I don't hear from anyone soon (e.g. for CCC approval)
I'll commit to the tl forest.

Martin

On Tue, Jun 30, 2009 at 11:28, Alan Bateman<Alan.Bateman at sun.com> wrote:
> Martin Buchholz wrote:
>>
>> :
>>
>> As you suggested, I added the Classpath exception wording
>> to TimSort.java and ComparableTimSort.java.
>>
>> I excised the old mergesort code from Arrays.java.
>>
>> webrev regenerated.
>
> Thanks for doing this.
>>
>> Adding all-or-nothing wording would be good to add,
>> perhaps to the class-level javadoc. ?But it doesn't
>> have to be part of this change.
>
> I brought it up because it looks like (and you can correct me) that the IAE
> may be thrown after some reordering of the array has taken place. This might
> be unexpected.
>
>>
>> The JDK project has unusually high compatibility concerns.
>> I and Josh believe the introduction of a possible IAE if the
>> comparator doesn't satisfy its contract is the right thing,
>> but we'd also be willing to change the code to swallow the IAE
>> or to do so conditionally based on the value of a system property.
>> Keep in mind that a call to foreign code can throw any throwable at all,
>> so a rogue comparator can cause arbitrary behavior even today.
>
> I think most people would agree that that catching these otherwise-silent
> failures is a good thing. The problem is the customer that upgrades the JDK
> on a production system and gets burnt by some broken third party code that
> "used" to work. Having some way to restore existing behavior would make this
> an easier sell. The suggestion from Jason to change it to an assertion might
> be worth thinking about too but I suspect that few developers test with
> assertions enabled.
>
> -Alan.
>


From Joe.Darcy at Sun.COM  Tue Jul  7 01:14:42 2009
From: Joe.Darcy at Sun.COM (Joe Darcy)
Date: Mon, 06 Jul 2009 18:14:42 -0700
Subject: Miscellaneous improvements to "jar".
In-Reply-To: <1ccfd1c10907061358w4815ce4by4145522e1c12edee@mail.gmail.com>
References: <1ccfd1c10906241934i21247553w685cf0b0b4cbd7b2@mail.gmail.com>
	<1ccfd1c10906251200n3bd78beek400abb51adcece40@mail.gmail.com>
	<1ccfd1c10906251757y72ccaca1l289dfc79f18b002c@mail.gmail.com>
	<4A450656.7070008@sun.com>
	<1ccfd1c10906270956g6c2f6208ne31f511ebcfaa41a@mail.gmail.com>
	<4A48555E.10900@sun.com>
	<1ccfd1c10907061358w4815ce4by4145522e1c12edee@mail.gmail.com>
Message-ID: <4A52A182.9070808@sun.com>

On 07/06/09 01:58 PM, Martin Buchholz wrote:
> I will atone for my use of nio2
> by providing the backport to openjdk6.
>
> 6854795: Miscellaneous improvements to "jar"
> 6834805: Improve jar -C performance
> 6332094: "jar t" and "jar x" should use ZipFile, not ZipInputStream
> 6496274: jar seems to use more CPU than it should
> Summary: backport jdk7 jar command (remove use of nio2)
>
> Assuming darcy and sherman agree,
> I will commit this to openjdk6.
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk6/jar-misc-6/
>
> Martin
>
> On Sun, Jun 28, 2009 at 22:47, Xueming Shen<Xueming.Shen at sun.com> wrote:
>   
>> (2)nio2 APIs are good, but now I can't not just copy/paste the jar Main to
>> 6.x:-)
>>     

Hello.

Yes, I think these changes would be a fine addition to OpenJDK 6 :-)  I 
gave the changes a quick look and didn't seen any thing amiss other than 
"Turkish" not being capitalized in:

497      * have the notorious "turkish i bug").

Sherman, please also take a look too.

Thanks,

-Joe


From i30817 at gmail.com  Tue Jul  7 01:28:44 2009
From: i30817 at gmail.com (Paulo Levi)
Date: Tue, 7 Jul 2009 02:28:44 +0100
Subject: Patching serviceloader
Message-ID: <212322090907061828v3e56c997ta3c1010707cc2014@mail.gmail.com>

I'd like to patch service loader to disable caching of services, but i
didn't sign the SUN agreement, or platform to test a jdk change. I suppose
jdk classes can be tested with the Xbootclasspath option right? (instead of
the whole project).

The reload method appears to already do this, but it needs to be called on
each iteration of ServiceProvider. It also re-reads the meta-inf/service
files. I would just like that each iterator would always return a new
object, and never read the service files more than once.

The options are creating 3 more static factory methods (so that
ServiceLoader is still effectily immutable).

Regardless, my suggestion to change the iterator would be this, if you could
remove the duplication, it would be nice too :

    public Iterator<S> iterator() {
    return new Iterator<S>() {

        Iterator<Map.Entry<String,S>> knownProviders
        = providers.entrySet().iterator();

        public boolean hasNext() {
        if (knownProviders.hasNext())
            return true;
        return lookupIterator.hasNext();
        }

        public S next() {
        if (knownProviders.hasNext())
            return newInstance(knownProviders.next().getValue());
        return lookupIterator.next();
        }

            private S newInstance(S object){
                if(cached){
                  return object;
                }
                String className = object.getClass().getCanonicalName();
                try {
                  return service.cast(Class.forName(className, true,
loader).newInstance());
                } catch (ClassNotFoundException x) {
                    fail(service, "Provider " + className + " not found");
                } catch (Throwable x) {
                    fail(service, "Provider " + className + " could not be
instantiated: " + x, x);
                }
            }


        public void remove() {
        throw new UnsupportedOperationException();
        }

    };
    }

the cached variable is a final one set on the static function factories.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090707/ba3e5c78/attachment.html>

From Joe.Darcy at Sun.COM  Tue Jul  7 04:57:54 2009
From: Joe.Darcy at Sun.COM (Joe Darcy)
Date: Mon, 06 Jul 2009 21:57:54 -0700
Subject: Review request for 6857803 Missing links to exceptions in javadoc for
	Class.getGeneric{Superclass, Interfaces}
Message-ID: <4A52D5D2.4010607@sun.com>

Hello.

Below is a simple patch for JDK 7 to fix a minor javadoc problem in 
java.lang.Clas.  The javadoc for methods getGenericSuperclass and 
getGenericInterfaces make @throws reference to two exceptions in the 
java.lang.reflect package; these exceptions don't get rendered as links 
in the HTML output because they are in a different package.  The fix is 
to add the package qualification; importing the exceptions would have 
worked too, but the imports are not needed by the code in java.lang.Class.

Thanks,

-Joe

--- old/src/share/classes/java/lang/Class.java    2009-07-06 
21:31:15.000000000 -0700
+++ new/src/share/classes/java/lang/Class.java    2009-07-06 
21:31:15.000000000 -0700
@@ -673,12 +673,12 @@
     * {@code Class} object representing the {@code Object} class is
     * returned.
     *
-     * @throws GenericSignatureFormatError if the generic
+     * @throws java.lang.reflect.GenericSignatureFormatError if the 
generic
     *     class signature does not conform to the format specified in the
     *     Java Virtual Machine Specification, 3rd edition
     * @throws TypeNotPresentException if the generic superclass
     *     refers to a non-existent type declaration
-     * @throws MalformedParameterizedTypeException if the
+     * @throws java.lang.reflect.MalformedParameterizedTypeException if 
the
     *     generic superclass refers to a parameterized type that cannot be
     *     instantiated  for any reason
     * @return the superclass of the class represented by this object
@@ -795,14 +795,14 @@
     * <p>If this object represents a primitive type or void, the
     * method returns an array of length 0.
     *
-     * @throws GenericSignatureFormatError
+     * @throws java.lang.reflect.GenericSignatureFormatError
     *     if the generic class signature does not conform to the format
     *     specified in the Java Virtual Machine Specification, 3rd edition
     * @throws TypeNotPresentException if any of the generic
     *     superinterfaces refers to a non-existent type declaration
-     * @throws MalformedParameterizedTypeException if any of the
-     *     generic superinterfaces refer to a parameterized type that 
cannot
-     *     be instantiated  for any reason
+     * @throws java.lang.reflect.MalformedParameterizedTypeException
+     *     if any of the generic superinterfaces refer to a parameterized
+     *     type that cannot be instantiated for any reason
     * @return an array of interfaces implemented by this class
     * @since 1.5
     */


From Xueming.Shen at Sun.COM  Tue Jul  7 06:00:03 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Mon, 06 Jul 2009 23:00:03 -0700
Subject: Miscellaneous improvements to "jar".
In-Reply-To: <4A52A182.9070808@sun.com>
References: <1ccfd1c10906241934i21247553w685cf0b0b4cbd7b2@mail.gmail.com>
	<1ccfd1c10906251200n3bd78beek400abb51adcece40@mail.gmail.com>
	<1ccfd1c10906251757y72ccaca1l289dfc79f18b002c@mail.gmail.com>
	<4A450656.7070008@sun.com>
	<1ccfd1c10906270956g6c2f6208ne31f511ebcfaa41a@mail.gmail.com>
	<4A48555E.10900@sun.com>
	<1ccfd1c10907061358w4815ce4by4145522e1c12edee@mail.gmail.com>
	<4A52A182.9070808@sun.com>
Message-ID: <4A52E463.10500@sun.com>

looks good.


Joe Darcy wrote:
> On 07/06/09 01:58 PM, Martin Buchholz wrote:
>> I will atone for my use of nio2
>> by providing the backport to openjdk6.
>>
>> 6854795: Miscellaneous improvements to "jar"
>> 6834805: Improve jar -C performance
>> 6332094: "jar t" and "jar x" should use ZipFile, not ZipInputStream
>> 6496274: jar seems to use more CPU than it should
>> Summary: backport jdk7 jar command (remove use of nio2)
>>
>> Assuming darcy and sherman agree,
>> I will commit this to openjdk6.
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk6/jar-misc-6/
>>
>> Martin
>>
>> On Sun, Jun 28, 2009 at 22:47, Xueming Shen<Xueming.Shen at sun.com> wrote:
>>  
>>> (2)nio2 APIs are good, but now I can't not just copy/paste the jar 
>>> Main to
>>> 6.x:-)
>>>     
>
> Hello.
>
> Yes, I think these changes would be a fine addition to OpenJDK 6 :-)  
> I gave the changes a quick look and didn't seen any thing amiss other 
> than "Turkish" not being capitalized in:
>
> 497      * have the notorious "turkish i bug").
>
> Sherman, please also take a look too.
>
> Thanks,
>
> -Joe



From Christopher.Hegarty at Sun.COM  Tue Jul  7 08:18:51 2009
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland)
Date: Tue, 07 Jul 2009 09:18:51 +0100
Subject: Review request for 6857803 Missing links to exceptions in javadoc
	for	Class.getGeneric{Superclass, Interfaces}
In-Reply-To: <4A52D5D2.4010607@sun.com>
References: <4A52D5D2.4010607@sun.com>
Message-ID: <4A5304EB.3060606@sun.com>

Hi Joe,

The changes look good, but could I ask you to make the same change to 
the throws param for getTypeParameters. It looks like it has the same issue.

Thanks,
-Chris.

Joe Darcy wrote:
> Hello.
> 
> Below is a simple patch for JDK 7 to fix a minor javadoc problem in 
> java.lang.Clas.  The javadoc for methods getGenericSuperclass and 
> getGenericInterfaces make @throws reference to two exceptions in the 
> java.lang.reflect package; these exceptions don't get rendered as links 
> in the HTML output because they are in a different package.  The fix is 
> to add the package qualification; importing the exceptions would have 
> worked too, but the imports are not needed by the code in java.lang.Class.
> 
> Thanks,
> 
> -Joe
> 
> --- old/src/share/classes/java/lang/Class.java    2009-07-06 
> 21:31:15.000000000 -0700
> +++ new/src/share/classes/java/lang/Class.java    2009-07-06 
> 21:31:15.000000000 -0700
> @@ -673,12 +673,12 @@
>     * {@code Class} object representing the {@code Object} class is
>     * returned.
>     *
> -     * @throws GenericSignatureFormatError if the generic
> +     * @throws java.lang.reflect.GenericSignatureFormatError if the 
> generic
>     *     class signature does not conform to the format specified in the
>     *     Java Virtual Machine Specification, 3rd edition
>     * @throws TypeNotPresentException if the generic superclass
>     *     refers to a non-existent type declaration
> -     * @throws MalformedParameterizedTypeException if the
> +     * @throws java.lang.reflect.MalformedParameterizedTypeException if 
> the
>     *     generic superclass refers to a parameterized type that cannot be
>     *     instantiated  for any reason
>     * @return the superclass of the class represented by this object
> @@ -795,14 +795,14 @@
>     * <p>If this object represents a primitive type or void, the
>     * method returns an array of length 0.
>     *
> -     * @throws GenericSignatureFormatError
> +     * @throws java.lang.reflect.GenericSignatureFormatError
>     *     if the generic class signature does not conform to the format
>     *     specified in the Java Virtual Machine Specification, 3rd edition
>     * @throws TypeNotPresentException if any of the generic
>     *     superinterfaces refers to a non-existent type declaration
> -     * @throws MalformedParameterizedTypeException if any of the
> -     *     generic superinterfaces refer to a parameterized type that 
> cannot
> -     *     be instantiated  for any reason
> +     * @throws java.lang.reflect.MalformedParameterizedTypeException
> +     *     if any of the generic superinterfaces refer to a parameterized
> +     *     type that cannot be instantiated for any reason
>     * @return an array of interfaces implemented by this class
>     * @since 1.5
>     */


From Christopher.Hegarty at Sun.COM  Tue Jul  7 09:51:56 2009
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland)
Date: Tue, 07 Jul 2009 10:51:56 +0100
Subject: timsort
In-Reply-To: <1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
Message-ID: <4A531ABC.6010805@sun.com>

Hi Martin,

Sorry for joining the party late...

I think adding the system property should take care of the compatibility 
issues, at least giving the user the ability to revert to the old 
behavior if they so choose.

I have a few minor comments ( if these issue have been discussed already 
I apologize ):

1) Should we update the Arrays class description and appropriate sort
    methods to now refer to timsort instead of saying: "The sorting
    algorithm is a modified mergesort...". I know this is not strictly
    necessary, but you must have considered it already, right?
2) With the addition of @throws IllegalArgumentException, this
    condition cannot be met with the old merge sort right, i.e. running
    with -Djava.util.Arrays.useLegacyMergeSort=true. So we're saying
    that all bets are off when running with this property set?
3) Have I missed something obvious! Can the test run, or even compile?
    Sorter.java, L29:
      ComparableTimSort.sort(array);

BTW, if you agree, I think we should stick with the process as is today 
for making spec changes. Once agreed, I can submit a CCC request for 
this change and help with the communication to get it approved.

-Chris.




Martin Buchholz wrote:
> No one actually said NO, but both Alan and Andrew strongly hinted that
> a backward compatibility mode would be good.
> So I kept the old implementation and allow it to be selectable
> via a system property.  There's nothing more compatible than
> the legacy implementation.
> 
>     /**
>      * Old merge sort implementation can be selected (for
>      * compatibility with broken comparators) using a system property.
>      * Cannot be a static boolean in the enclosing class due to
>      * circular dependencies.  To be removed in a future release.
>      */
>     static final class LegacyMergeSort {
>         private static final boolean userRequested =
>             java.security.AccessController.doPrivileged(
>                 new sun.security.action.GetBooleanAction(
>                     "java.util.Arrays.useLegacyMergeSort")).booleanValue();
>     }
> 
> The sort method bodies now look like:
> 
>         if (LegacyMergeSort.userRequested)
>             legacyMergeSort(a);
>         else
>             ComparableTimSort.sort(a);
> 
> New webrev at:
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/
> 
> If I don't hear from anyone soon (e.g. for CCC approval)
> I'll commit to the tl forest.
> 
> Martin
> 
> On Tue, Jun 30, 2009 at 11:28, Alan Bateman<Alan.Bateman at sun.com> wrote:
>> Martin Buchholz wrote:
>>> :
>>>
>>> As you suggested, I added the Classpath exception wording
>>> to TimSort.java and ComparableTimSort.java.
>>>
>>> I excised the old mergesort code from Arrays.java.
>>>
>>> webrev regenerated.
>> Thanks for doing this.
>>> Adding all-or-nothing wording would be good to add,
>>> perhaps to the class-level javadoc.  But it doesn't
>>> have to be part of this change.
>> I brought it up because it looks like (and you can correct me) that the IAE
>> may be thrown after some reordering of the array has taken place. This might
>> be unexpected.
>>
>>> The JDK project has unusually high compatibility concerns.
>>> I and Josh believe the introduction of a possible IAE if the
>>> comparator doesn't satisfy its contract is the right thing,
>>> but we'd also be willing to change the code to swallow the IAE
>>> or to do so conditionally based on the value of a system property.
>>> Keep in mind that a call to foreign code can throw any throwable at all,
>>> so a rogue comparator can cause arbitrary behavior even today.
>> I think most people would agree that that catching these otherwise-silent
>> failures is a good thing. The problem is the customer that upgrades the JDK
>> on a production system and gets burnt by some broken third party code that
>> "used" to work. Having some way to restore existing behavior would make this
>> an easier sell. The suggestion from Jason to change it to an assertion might
>> be worth thinking about too but I suspect that few developers test with
>> assertions enabled.
>>
>> -Alan.
>>


From gnu_andrew at member.fsf.org  Tue Jul  7 10:05:11 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Tue, 7 Jul 2009 11:05:11 +0100
Subject: timsort
In-Reply-To: <4A531ABC.6010805@sun.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
Message-ID: <17c6771e0907070305m11657754w7661b4150f75cfdc@mail.gmail.com>

2009/7/7 Christopher Hegarty -Sun Microsystems Ireland
<Christopher.Hegarty at sun.com>:
> Hi Martin,
>
> Sorry for joining the party late...
>
> I think adding the system property should take care of the compatibility
> issues, at least giving the user the ability to revert to the old behavior
> if they so choose.
>
> I have a few minor comments ( if these issue have been discussed already I
> apologize ):
>
> 1) Should we update the Arrays class description and appropriate sort
> ? methods to now refer to timsort instead of saying: "The sorting
> ? algorithm is a modified mergesort...". I know this is not strictly
> ? necessary, but you must have considered it already, right?
> 2) With the addition of @throws IllegalArgumentException, this
> ? condition cannot be met with the old merge sort right, i.e. running
> ? with -Djava.util.Arrays.useLegacyMergeSort=true. So we're saying
> ? that all bets are off when running with this property set?
> 3) Have I missed something obvious! Can the test run, or even compile?
> ? Sorter.java, L29:
> ? ? ComparableTimSort.sort(array);
>
> BTW, if you agree, I think we should stick with the process as is today for
> making spec changes. Once agreed, I can submit a CCC request for this change
> and help with the communication to get it approved.
>
> -Chris.
>
>
>
>
> Martin Buchholz wrote:
>>
>> No one actually said NO, but both Alan and Andrew strongly hinted that
>> a backward compatibility mode would be good.
>> So I kept the old implementation and allow it to be selectable
>> via a system property. ?There's nothing more compatible than
>> the legacy implementation.
>>
>> ? ?/**
>> ? ? * Old merge sort implementation can be selected (for
>> ? ? * compatibility with broken comparators) using a system property.
>> ? ? * Cannot be a static boolean in the enclosing class due to
>> ? ? * circular dependencies. ?To be removed in a future release.
>> ? ? */
>> ? ?static final class LegacyMergeSort {
>> ? ? ? ?private static final boolean userRequested =
>> ? ? ? ? ? ?java.security.AccessController.doPrivileged(
>> ? ? ? ? ? ? ? ?new sun.security.action.GetBooleanAction(
>> ? ? ? ? ? ? ? ? ? ?"java.util.Arrays.useLegacyMergeSort")).booleanValue();
>> ? ?}
>>
>> The sort method bodies now look like:
>>
>> ? ? ? ?if (LegacyMergeSort.userRequested)
>> ? ? ? ? ? ?legacyMergeSort(a);
>> ? ? ? ?else
>> ? ? ? ? ? ?ComparableTimSort.sort(a);
>>
>> New webrev at:
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/
>>
>> If I don't hear from anyone soon (e.g. for CCC approval)
>> I'll commit to the tl forest.
>>
>> Martin
>>
>> On Tue, Jun 30, 2009 at 11:28, Alan Bateman<Alan.Bateman at sun.com> wrote:
>>>
>>> Martin Buchholz wrote:
>>>>
>>>> :
>>>>
>>>> As you suggested, I added the Classpath exception wording
>>>> to TimSort.java and ComparableTimSort.java.
>>>>
>>>> I excised the old mergesort code from Arrays.java.
>>>>
>>>> webrev regenerated.
>>>
>>> Thanks for doing this.
>>>>
>>>> Adding all-or-nothing wording would be good to add,
>>>> perhaps to the class-level javadoc. ?But it doesn't
>>>> have to be part of this change.
>>>
>>> I brought it up because it looks like (and you can correct me) that the
>>> IAE
>>> may be thrown after some reordering of the array has taken place. This
>>> might
>>> be unexpected.
>>>
>>>> The JDK project has unusually high compatibility concerns.
>>>> I and Josh believe the introduction of a possible IAE if the
>>>> comparator doesn't satisfy its contract is the right thing,
>>>> but we'd also be willing to change the code to swallow the IAE
>>>> or to do so conditionally based on the value of a system property.
>>>> Keep in mind that a call to foreign code can throw any throwable at all,
>>>> so a rogue comparator can cause arbitrary behavior even today.
>>>
>>> I think most people would agree that that catching these otherwise-silent
>>> failures is a good thing. The problem is the customer that upgrades the
>>> JDK
>>> on a production system and gets burnt by some broken third party code
>>> that
>>> "used" to work. Having some way to restore existing behavior would make
>>> this
>>> an easier sell. The suggestion from Jason to change it to an assertion
>>> might
>>> be worth thinking about too but I suspect that few developers test with
>>> assertions enabled.
>>>
>>> -Alan.
>>>
>

Forgive the naivety, but what is a 'CCC request'?  Is this process of
requesting and approving specification changes public?  I'm sure I'm
not alone among those contributing to the JDK only since its inception
as OpenJDK and thus unaware of such procedures, so some explanation
would be helpful.

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Christopher.Hegarty at Sun.COM  Tue Jul  7 10:33:35 2009
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland)
Date: Tue, 07 Jul 2009 11:33:35 +0100
Subject: timsort
In-Reply-To: <17c6771e0907070305m11657754w7661b4150f75cfdc@mail.gmail.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
	<17c6771e0907070305m11657754w7661b4150f75cfdc@mail.gmail.com>
Message-ID: <4A53247F.8020405@sun.com>



Andrew John Hughes wrote:
> [snip]
> 
> Forgive the naivety, but what is a 'CCC request'?  Is this process of
> requesting and approving specification changes public?  I'm sure I'm
> not alone among those contributing to the JDK only since its inception
> as OpenJDK and thus unaware of such procedures, so some explanation
> would be helpful.

The CCC process is referred to in the developers guide, under 'Change 
Planning and Guidelines' [1]. It doesn't explain what the CCC stands for 
or how it works, but I found a mail that Iris sent some time ago which 
explains a little about it [2]. Relevant section:

"I'm not quite sure what "CCC" stands for (and I'm on it :) ).  In the
back of my mind, I think it stands for "Committee for Concerned
Citizens", but that could have been a punchline for a joke.

Nevertheless, the CCC is ann important part of our current process.
It is responsible for auditing anything that would change spec or
externally visible behaviour in the JDK, such as adding a new API,
tool option, or system property.

The CCC is one of the "Process Tools" for interface review and change
approval that Mark references in this blog:

   Upcoming OpenJDK infrastructure projects
   http://blogs.sun.com/mr/entry/under_construction

I'll provide a definition of CCC and reference it in the Guide as
appropriate.  We'll need to keep in mind that the this review body's
function (and possibly name) will likely change as as externalize its
function.  For this reason, we've been reluctant to provide much
documentation about it."


-Chris.

[1] http://openjdk.java.net/guide/changePlanning.html
[2] 
http://mail.openjdk.java.net/pipermail/guide-discuss/2008-February/000008.html

> 
> Thanks,


From martinrb at google.com  Tue Jul  7 11:20:30 2009
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 7 Jul 2009 04:20:30 -0700
Subject: timsort
In-Reply-To: <4A531ABC.6010805@sun.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
Message-ID: <1ccfd1c10907070420v17a72491je35246d61c510868@mail.gmail.com>

[+jjb]  (Please keep Josh in this thread - he is the primary author)


On Tue, Jul 7, 2009 at 02:51, Christopher Hegarty -Sun Microsystems Ireland
<Christopher.Hegarty at sun.com> wrote:

> Hi Martin,
>
> Sorry for joining the party late...
>
> I think adding the system property should take care of the compatibility
> issues, at least giving the user the ability to revert to the old behavior
> if they so choose.
>
> I have a few minor comments ( if these issue have been discussed already I
> apologize ):
>
> 1) Should we update the Arrays class description and appropriate sort
>   methods to now refer to timsort instead of saying: "The sorting
>   algorithm is a modified mergesort...". I know this is not strictly
>   necessary, but you must have considered it already, right?


Josh?


>
> 2) With the addition of @throws IllegalArgumentException, this
>   condition cannot be met with the old merge sort right, i.e. running
>   with -Djava.util.Arrays.useLegacyMergeSort=true. So we're saying
>   that all bets are off when running with this property set?


No.  Please re-read the @throws IllegalArgumentException.
It is carefully worded to make no promises at all.  All bets are off -
period.
No JCK tests can be written or are invalidated.


>
> 3) Have I missed something obvious! Can the test run, or even compile?
>   Sorter.java, L29:
>     ComparableTimSort.sort(array);
>

These are not tests.
Please see:
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/raw_files/new/test/java/util/TimSort/README

One could rework the benchmarks to work with the newly introduced
system property (using reflection to invoke appropriate methods)
but I have no plans to do that.


>
> BTW, if you agree, I think we should stick with the process as is today for
> making spec changes. Once agreed, I can submit a CCC request for this change
> and help with the communication to get it approved.
>

OK.  Keep in mind that the spec changes are almost no-ops.

Martin


>
> -Chris.
>
>
>
>
>
> Martin Buchholz wrote:
>
>> No one actually said NO, but both Alan and Andrew strongly hinted that
>> a backward compatibility mode would be good.
>> So I kept the old implementation and allow it to be selectable
>> via a system property.  There's nothing more compatible than
>> the legacy implementation.
>>
>>    /**
>>     * Old merge sort implementation can be selected (for
>>     * compatibility with broken comparators) using a system property.
>>     * Cannot be a static boolean in the enclosing class due to
>>     * circular dependencies.  To be removed in a future release.
>>     */
>>    static final class LegacyMergeSort {
>>        private static final boolean userRequested =
>>            java.security.AccessController.doPrivileged(
>>                new sun.security.action.GetBooleanAction(
>>                    "java.util.Arrays.useLegacyMergeSort")).booleanValue();
>>    }
>>
>> The sort method bodies now look like:
>>
>>        if (LegacyMergeSort.userRequested)
>>            legacyMergeSort(a);
>>        else
>>            ComparableTimSort.sort(a);
>>
>> New webrev at:
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/<http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/timsort/>
>>
>> If I don't hear from anyone soon (e.g. for CCC approval)
>> I'll commit to the tl forest.
>>
>> Martin
>>
>> On Tue, Jun 30, 2009 at 11:28, Alan Bateman<Alan.Bateman at sun.com> wrote:
>>
>>> Martin Buchholz wrote:
>>>
>>>> :
>>>>
>>>> As you suggested, I added the Classpath exception wording
>>>> to TimSort.java and ComparableTimSort.java.
>>>>
>>>> I excised the old mergesort code from Arrays.java.
>>>>
>>>> webrev regenerated.
>>>>
>>> Thanks for doing this.
>>>
>>>> Adding all-or-nothing wording would be good to add,
>>>> perhaps to the class-level javadoc.  But it doesn't
>>>> have to be part of this change.
>>>>
>>> I brought it up because it looks like (and you can correct me) that the
>>> IAE
>>> may be thrown after some reordering of the array has taken place. This
>>> might
>>> be unexpected.
>>>
>>>  The JDK project has unusually high compatibility concerns.
>>>> I and Josh believe the introduction of a possible IAE if the
>>>> comparator doesn't satisfy its contract is the right thing,
>>>> but we'd also be willing to change the code to swallow the IAE
>>>> or to do so conditionally based on the value of a system property.
>>>> Keep in mind that a call to foreign code can throw any throwable at all,
>>>> so a rogue comparator can cause arbitrary behavior even today.
>>>>
>>> I think most people would agree that that catching these otherwise-silent
>>> failures is a good thing. The problem is the customer that upgrades the
>>> JDK
>>> on a production system and gets burnt by some broken third party code
>>> that
>>> "used" to work. Having some way to restore existing behavior would make
>>> this
>>> an easier sell. The suggestion from Jason to change it to an assertion
>>> might
>>> be worth thinking about too but I suspect that few developers test with
>>> assertions enabled.
>>>
>>> -Alan.
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090707/61812be7/attachment.html>

From gnu_andrew at member.fsf.org  Tue Jul  7 11:35:48 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Tue, 7 Jul 2009 12:35:48 +0100
Subject: timsort
In-Reply-To: <4A53247F.8020405@sun.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
	<17c6771e0907070305m11657754w7661b4150f75cfdc@mail.gmail.com>
	<4A53247F.8020405@sun.com>
Message-ID: <17c6771e0907070435t28e16ae4n68a481eca4281f1e@mail.gmail.com>

2009/7/7 Christopher Hegarty -Sun Microsystems Ireland
<Christopher.Hegarty at sun.com>:
>
>
> Andrew John Hughes wrote:
>>
>> [snip]
>>
>> Forgive the naivety, but what is a 'CCC request'? ?Is this process of
>> requesting and approving specification changes public? ?I'm sure I'm
>> not alone among those contributing to the JDK only since its inception
>> as OpenJDK and thus unaware of such procedures, so some explanation
>> would be helpful.
>
> The CCC process is referred to in the developers guide, under 'Change
> Planning and Guidelines' [1]. It doesn't explain what the CCC stands for or
> how it works, but I found a mail that Iris sent some time ago which explains
> a little about it [2]. Relevant section:
>
> "I'm not quite sure what "CCC" stands for (and I'm on it :) ). ?In the
> back of my mind, I think it stands for "Committee for Concerned
> Citizens", but that could have been a punchline for a joke.
>
> Nevertheless, the CCC is ann important part of our current process.
> It is responsible for auditing anything that would change spec or
> externally visible behaviour in the JDK, such as adding a new API,
> tool option, or system property.
>
> The CCC is one of the "Process Tools" for interface review and change
> approval that Mark references in this blog:
>
> ?Upcoming OpenJDK infrastructure projects
> ?http://blogs.sun.com/mr/entry/under_construction
>
> I'll provide a definition of CCC and reference it in the Guide as
> appropriate. ?We'll need to keep in mind that the this review body's
> function (and possibly name) will likely change as as externalize its
> function. ?For this reason, we've been reluctant to provide much
> documentation about it."
>
>
> -Chris.
>
> [1] http://openjdk.java.net/guide/changePlanning.html
> [2]
> http://mail.openjdk.java.net/pipermail/guide-discuss/2008-February/000008.html
>
>>
>> Thanks,
>

Thanks for reminding me about this post.  This stuff does seem vaguely
familiar now... :)

It is, however, rather disappointing that we've so far failed to
achieve most of the things Mark highlights in this blog.  I've CCed
Mark on this email to see if he can shed any light on current
progress.  Without wanting to enter into too much speculation, I would
guess conditions at Sun have not been ideal since this blog was
published, and this has diminished the ability to complete these
tasks.

I'm assuming that the quarters referred to are from the start of the
year, as matches the appearance of the Mercurial forests, rather than
this being the financial year system.

* Code-review publication: Scheduled for Q4/2007, appeared in Q1/2009.
* Core community database: Scheduled for Q4/2007, as yet no public
interface although it presumably exists behind the scenes (we have SSH
keys, etc. but the only way of modifying this information that I know
of is by pestering Mark Reinhold).
* Public Mercurial forests: Scheduled for Q4/2007, appeared Q4/2007,
becoming more active as time goes on.
* Mercurial forest management: Scheduled for Q1/2008, although
external contributors have push rights, these are global as far as I
can tell, and there is no ability for us to create subprojects, etc.
* OpenGrok: Scheduled for Q1/2008, nothing as yet.
* Improved content publishing: Scheduled for Q2/2008, not sure what
this involves as I've never seen the internal variant, but nothing
visible as yet.
* Process tools: Scheduled for Q2/2008, nothing so far.
* Bug database: Scheduled for 2008, appeared Q1/2009.
* Distributed build system: Scheduled for 2008, nothing so far.

Please let us know if there's anything we can do to help with these.
I assume there has been some internal progress, but there is nothing
public on most of these so far.  A few are just niceties (like
OpenGrok, distributed builds), but things like the process tools are
presumably quite vital in the development of JDK7.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From martinrb at google.com  Tue Jul  7 12:47:44 2009
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 7 Jul 2009 05:47:44 -0700
Subject: Review request for 5049299
In-Reply-To: <1ccfd1c10907011628o68bca87ei76f9a92e3f0af970@mail.gmail.com>
References: <4A1678DB.9010209@sun.com> <4A40E7C0.5080308@redhat.com>
	<1ccfd1c10906271035g660800a5n7de04efc6f1ce504@mail.gmail.com>
	<20090628023345.C970A420F6@magilla.sf.frob.com>
	<1ccfd1c10906291823p366255e5t678bcade6c5aa08@mail.gmail.com>
	<20090630022822.2F69F420F6@magilla.sf.frob.com>
	<4A49DF55.5090807@sun.com>
	<1ccfd1c10906301639j68a389a8w7cac8c235d72c5c0@mail.gmail.com>
	<4A4B5CA6.90607@sun.com>
	<1ccfd1c10907011628o68bca87ei76f9a92e3f0af970@mail.gmail.com>
Message-ID: <1ccfd1c10907070547i1632616fk8934c338d3c51e1c@mail.gmail.com>

I just noticed:
5049299 has its own web site:
http://www.forkndie.com/

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090707/e419b5ba/attachment.html>

From Christopher.Hegarty at Sun.COM  Tue Jul  7 14:35:20 2009
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland)
Date: Tue, 07 Jul 2009 15:35:20 +0100
Subject: timsort
In-Reply-To: <1ccfd1c10907070420v17a72491je35246d61c510868@mail.gmail.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
	<1ccfd1c10907070420v17a72491je35246d61c510868@mail.gmail.com>
Message-ID: <4A535D28.6090407@sun.com>

comments inline...

Martin Buchholz wrote:
> [+jjb]  (Please keep Josh in this thread - he is the primary author)
> 
> 
> On Tue, Jul 7, 2009 at 02:51, Christopher Hegarty -Sun Microsystems 
> Ireland <Christopher.Hegarty at sun.com 
> <mailto:Christopher.Hegarty at sun.com>> wrote:
> 
>     Hi Martin,
> 
>     Sorry for joining the party late...
> 
>     I think adding the system property should take care of the
>     compatibility issues, at least giving the user the ability to revert
>     to the old behavior if they so choose.
> 
>     I have a few minor comments ( if these issue have been discussed
>     already I apologize ):
> 
>     1) Should we update the Arrays class description and appropriate sort
>       methods to now refer to timsort instead of saying: "The sorting
>       algorithm is a modified mergesort...". I know this is not strictly
>       necessary, but you must have considered it already, right?
> 
> 
> Josh?
>  
> 
> 
>     2) With the addition of @throws IllegalArgumentException, this
>       condition cannot be met with the old merge sort right, i.e. running
>       with -Djava.util.Arrays.useLegacyMergeSort=true. So we're saying
>       that all bets are off when running with this property set?
> 
> 
> No.  Please re-read the @throws IllegalArgumentException.
> It is carefully worded to make no promises at all.  All bets are off - 
> period.
OK great. But just to clarify, what exactly does "if the natural order 
of the array elements is found to violate the Comparable contract" mean?

> No JCK tests can be written or are invalidated.
>  
> 
> 
>     3) Have I missed something obvious! Can the test run, or even compile?
>       Sorter.java, L29:
>         ComparableTimSort.sort(array);
> 
> 
> These are not tests.
> Please see:
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/raw_files/new/test/java/util/TimSort/README
Yes, I only noticed that after sending the mail.

> One could rework the benchmarks to work with the newly introduced
> system property (using reflection to invoke appropriate methods)
> but I have no plans to do that.
>  
> 
> 
>     BTW, if you agree, I think we should stick with the process as is
>     today for making spec changes. Once agreed, I can submit a CCC
>     request for this change and help with the communication to get it
>     approved.
> 
> 
> OK.  Keep in mind that the spec changes are almost no-ops.
Once I understand the impact of the spec change then I hope the 
fasttrack the CCC request.

-Chris.
> 
> Martin
>  
> 
> 
>     -Chris.
> 
> 
> 
> 
> 
>     Martin Buchholz wrote:
> 
>         No one actually said NO, but both Alan and Andrew strongly
>         hinted that
>         a backward compatibility mode would be good.
>         So I kept the old implementation and allow it to be selectable
>         via a system property.  There's nothing more compatible than
>         the legacy implementation.
> 
>            /**
>             * Old merge sort implementation can be selected (for
>             * compatibility with broken comparators) using a system
>         property.
>             * Cannot be a static boolean in the enclosing class due to
>             * circular dependencies.  To be removed in a future release.
>             */
>            static final class LegacyMergeSort {
>                private static final boolean userRequested =
>                    java.security.AccessController.doPrivileged(
>                        new sun.security.action.GetBooleanAction(
>                          
>          "java.util.Arrays.useLegacyMergeSort")).booleanValue();
>            }
> 
>         The sort method bodies now look like:
> 
>                if (LegacyMergeSort.userRequested)
>                    legacyMergeSort(a);
>                else
>                    ComparableTimSort.sort(a);
> 
>         New webrev at:
>         http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/
>         <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/timsort/>
> 
>         If I don't hear from anyone soon (e.g. for CCC approval)
>         I'll commit to the tl forest.
> 
>         Martin
> 
>         On Tue, Jun 30, 2009 at 11:28, Alan Bateman<Alan.Bateman at sun.com
>         <mailto:Alan.Bateman at sun.com>> wrote:
> 
>             Martin Buchholz wrote:
> 
>                 :
> 
>                 As you suggested, I added the Classpath exception wording
>                 to TimSort.java and ComparableTimSort.java.
> 
>                 I excised the old mergesort code from Arrays.java.
> 
>                 webrev regenerated.
> 
>             Thanks for doing this.
> 
>                 Adding all-or-nothing wording would be good to add,
>                 perhaps to the class-level javadoc.  But it doesn't
>                 have to be part of this change.
> 
>             I brought it up because it looks like (and you can correct
>             me) that the IAE
>             may be thrown after some reordering of the array has taken
>             place. This might
>             be unexpected.
> 
>                 The JDK project has unusually high compatibility concerns.
>                 I and Josh believe the introduction of a possible IAE if the
>                 comparator doesn't satisfy its contract is the right thing,
>                 but we'd also be willing to change the code to swallow
>                 the IAE
>                 or to do so conditionally based on the value of a system
>                 property.
>                 Keep in mind that a call to foreign code can throw any
>                 throwable at all,
>                 so a rogue comparator can cause arbitrary behavior even
>                 today.
> 
>             I think most people would agree that that catching these
>             otherwise-silent
>             failures is a good thing. The problem is the customer that
>             upgrades the JDK
>             on a production system and gets burnt by some broken third
>             party code that
>             "used" to work. Having some way to restore existing behavior
>             would make this
>             an easier sell. The suggestion from Jason to change it to an
>             assertion might
>             be worth thinking about too but I suspect that few
>             developers test with
>             assertions enabled.
> 
>             -Alan.
> 
> 


From martinrb at google.com  Tue Jul  7 15:22:34 2009
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 7 Jul 2009 08:22:34 -0700
Subject: timsort
In-Reply-To: <4A535D28.6090407@sun.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
	<1ccfd1c10907070420v17a72491je35246d61c510868@mail.gmail.com>
	<4A535D28.6090407@sun.com>
Message-ID: <1ccfd1c10907070822n69299c4cjafb40a36615928b4@mail.gmail.com>

On Tue, Jul 7, 2009 at 07:35, Christopher Hegarty -Sun Microsystems Ireland
>
>
>>
>>    2) With the addition of @throws IllegalArgumentException, this
>>      condition cannot be met with the old merge sort right, i.e. running
>>      with -Djava.util.Arrays.useLegacyMergeSort=true. So we're saying
>>      that all bets are off when running with this property set?
>>
>>
>> No.  Please re-read the @throws IllegalArgumentException.
>> It is carefully worded to make no promises at all.  All bets are off -
>> period.
>>
> OK great. But just to clarify, what exactly does "if the natural order of
> the array elements is found to violate the Comparable contract" mean?
>

"natural order" is defined in the Comparable javadoc.

http://download.java.net/jdk7/docs/api/java/lang/Comparable.html

We could use @linkplain to the Comparable spec, as elsewhere in java.util.

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090707/ad821976/attachment.html>

From Christopher.Hegarty at Sun.COM  Tue Jul  7 15:57:05 2009
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland)
Date: Tue, 07 Jul 2009 16:57:05 +0100
Subject: timsort
In-Reply-To: <1ccfd1c10907070822n69299c4cjafb40a36615928b4@mail.gmail.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
	<1ccfd1c10907070420v17a72491je35246d61c510868@mail.gmail.com>
	<4A535D28.6090407@sun.com>
	<1ccfd1c10907070822n69299c4cjafb40a36615928b4@mail.gmail.com>
Message-ID: <4A537051.2040803@sun.com>

Martin Buchholz wrote:
> 
> 
> On Tue, Jul 7, 2009 at 07:35, Christopher Hegarty -Sun Microsystems Ireland
> 
> 
> 
>            2) With the addition of @throws IllegalArgumentException, this
>              condition cannot be met with the old merge sort right, i.e.
>         running
>              with -Djava.util.Arrays.useLegacyMergeSort=true. So we're
>         saying
>              that all bets are off when running with this property set?
> 
> 
>         No.  Please re-read the @throws IllegalArgumentException.
>         It is carefully worded to make no promises at all.  All bets are
>         off - period.
> 
>     OK great. But just to clarify, what exactly does "if the natural
>     order of the array elements is found to violate the Comparable
>     contract" mean?
> 
> 
> "natural order" is defined in the Comparable javadoc.
Sorry, I still don't see how this @throws can be a no-op. Is it not 
possible to craft an array of Comparables that violates the Comparable 
contract and therefore provoke the sort method to throw IAE?

-Chris.
>  
> http://download.java.net/jdk7/docs/api/java/lang/Comparable.html
> 
> We could use @linkplain to the Comparable spec, as elsewhere in java.util.
> 
> Martin


From Joe.Darcy at Sun.COM  Tue Jul  7 16:10:07 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Tue, 07 Jul 2009 09:10:07 -0700
Subject: Review request for 6857803 Missing links to exceptions in javadoc
	for	Class.getGeneric{Superclass, Interfaces}
In-Reply-To: <4A5304EB.3060606@sun.com>
References: <4A52D5D2.4010607@sun.com> <4A5304EB.3060606@sun.com>
Message-ID: <4A53735F.6090402@sun.com>

Christopher Hegarty -Sun Microsystems Ireland wrote:
> Hi Joe,
>
> The changes look good, but could I ask you to make the same change to 
> the throws param for getTypeParameters. It looks like it has the same 
> issue.

Good catch; I'll fix that too.

Thanks,

-Joe

>
> Thanks,
> -Chris.
>
> Joe Darcy wrote:
>> Hello.
>>
>> Below is a simple patch for JDK 7 to fix a minor javadoc problem in 
>> java.lang.Clas.  The javadoc for methods getGenericSuperclass and 
>> getGenericInterfaces make @throws reference to two exceptions in the 
>> java.lang.reflect package; these exceptions don't get rendered as 
>> links in the HTML output because they are in a different package.  
>> The fix is to add the package qualification; importing the exceptions 
>> would have worked too, but the imports are not needed by the code in 
>> java.lang.Class.
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/src/share/classes/java/lang/Class.java    2009-07-06 
>> 21:31:15.000000000 -0700
>> +++ new/src/share/classes/java/lang/Class.java    2009-07-06 
>> 21:31:15.000000000 -0700
>> @@ -673,12 +673,12 @@
>>     * {@code Class} object representing the {@code Object} class is
>>     * returned.
>>     *
>> -     * @throws GenericSignatureFormatError if the generic
>> +     * @throws java.lang.reflect.GenericSignatureFormatError if the 
>> generic
>>     *     class signature does not conform to the format specified in 
>> the
>>     *     Java Virtual Machine Specification, 3rd edition
>>     * @throws TypeNotPresentException if the generic superclass
>>     *     refers to a non-existent type declaration
>> -     * @throws MalformedParameterizedTypeException if the
>> +     * @throws java.lang.reflect.MalformedParameterizedTypeException 
>> if the
>>     *     generic superclass refers to a parameterized type that 
>> cannot be
>>     *     instantiated  for any reason
>>     * @return the superclass of the class represented by this object
>> @@ -795,14 +795,14 @@
>>     * <p>If this object represents a primitive type or void, the
>>     * method returns an array of length 0.
>>     *
>> -     * @throws GenericSignatureFormatError
>> +     * @throws java.lang.reflect.GenericSignatureFormatError
>>     *     if the generic class signature does not conform to the format
>>     *     specified in the Java Virtual Machine Specification, 3rd 
>> edition
>>     * @throws TypeNotPresentException if any of the generic
>>     *     superinterfaces refers to a non-existent type declaration
>> -     * @throws MalformedParameterizedTypeException if any of the
>> -     *     generic superinterfaces refer to a parameterized type 
>> that cannot
>> -     *     be instantiated  for any reason
>> +     * @throws java.lang.reflect.MalformedParameterizedTypeException
>> +     *     if any of the generic superinterfaces refer to a 
>> parameterized
>> +     *     type that cannot be instantiated for any reason
>>     * @return an array of interfaces implemented by this class
>>     * @since 1.5
>>     */



From martinrb at google.com  Tue Jul  7 16:33:46 2009
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 7 Jul 2009 09:33:46 -0700
Subject: timsort
In-Reply-To: <4A537051.2040803@sun.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
	<1ccfd1c10907070420v17a72491je35246d61c510868@mail.gmail.com>
	<4A535D28.6090407@sun.com>
	<1ccfd1c10907070822n69299c4cjafb40a36615928b4@mail.gmail.com>
	<4A537051.2040803@sun.com>
Message-ID: <1ccfd1c10907070933u5ba165a5qe1fe2a61a976f4b@mail.gmail.com>

On Tue, Jul 7, 2009 at 08:57, Christopher Hegarty -Sun Microsystems
Ireland<Christopher.Hegarty at sun.com> wrote:
> Martin Buchholz wrote:
>>
>>
>> On Tue, Jul 7, 2009 at 07:35, Christopher Hegarty -Sun Microsystems
>> Ireland
>>
>>
>>
>> ? ? ? ? ? 2) With the addition of @throws IllegalArgumentException, this
>> ? ? ? ? ? ? condition cannot be met with the old merge sort right, i.e.
>> ? ? ? ?running
>> ? ? ? ? ? ? with -Djava.util.Arrays.useLegacyMergeSort=true. So we're
>> ? ? ? ?saying
>> ? ? ? ? ? ? that all bets are off when running with this property set?
>>
>>
>> ? ? ? ?No. ?Please re-read the @throws IllegalArgumentException.
>> ? ? ? ?It is carefully worded to make no promises at all. ?All bets are
>> ? ? ? ?off - period.
>>
>> ? ?OK great. But just to clarify, what exactly does "if the natural
>> ? ?order of the array elements is found to violate the Comparable
>> ? ?contract" mean?
>>
>>
>> "natural order" is defined in the Comparable javadoc.
>
> Sorry, I still don't see how this @throws can be a no-op. Is it not possible
> to craft an array of Comparables that violates the Comparable contract and
> therefore provoke the sort method to throw IAE?

It is not feasible to check whether a particular implementation of Comparable
violates the Comparable contract - there are too many ways the contract
can be violated, and checking may be too expensive.

+     * @throws IllegalArgumentException if the natural order of the array
+     *         elements is found to violate the {@link Comparable} contract

So the proposed spec does not and cannot require any exception to be thrown.
What is proposed is *if* the implementation happens to check for violations
and if it chooses to throw an exception, then IAE is the exception type
that will be used.

Perhaps someone could come up with clearer wording than "is found to violate"?

Martin

> -Chris.
>>
>> ?http://download.java.net/jdk7/docs/api/java/lang/Comparable.html
>>
>> We could use @linkplain to the Comparable spec, as elsewhere in java.util.
>>
>> Martin
>


From David.Holmes at Sun.COM  Tue Jul  7 16:42:03 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Wed, 08 Jul 2009 02:42:03 +1000
Subject: timsort
In-Reply-To: <1ccfd1c10907070933u5ba165a5qe1fe2a61a976f4b@mail.gmail.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
	<1ccfd1c10907070420v17a72491je35246d61c510868@mail.gmail.com>
	<4A535D28.6090407@sun.com>
	<1ccfd1c10907070822n69299c4cjafb40a36615928b4@mail.gmail.com>
	<4A537051.2040803@sun.com>
	<1ccfd1c10907070933u5ba165a5qe1fe2a61a976f4b@mail.gmail.com>
Message-ID: <4A537ADB.7060206@sun.com>

Martin Buchholz said the following on 07/08/09 02:33:
> +     * @throws IllegalArgumentException if the natural order of the array
> +     *         elements is found to violate the {@link Comparable} contract
> 
> So the proposed spec does not and cannot require any exception to be thrown.
> What is proposed is *if* the implementation happens to check for violations
> and if it chooses to throw an exception, then IAE is the exception type
> that will be used.
> 
> Perhaps someone could come up with clearer wording than "is found to violate"?

How about:

+     * @throws IllegalArgumentException if this implementation detects
+     *  that the natural order of the array elements violates the
+     *  {@link Comparable} contract

David


From Joel.Kamentz at sas.com  Tue Jul  7 16:44:03 2009
From: Joel.Kamentz at sas.com (Joel Kamentz)
Date: Tue, 7 Jul 2009 12:44:03 -0400
Subject: timsort
In-Reply-To: <1ccfd1c10907070933u5ba165a5qe1fe2a61a976f4b@mail.gmail.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
	<1ccfd1c10907070420v17a72491je35246d61c510868@mail.gmail.com>
	<4A535D28.6090407@sun.com>
	<1ccfd1c10907070822n69299c4cjafb40a36615928b4@mail.gmail.com>
	<4A537051.2040803@sun.com>
	<1ccfd1c10907070933u5ba165a5qe1fe2a61a976f4b@mail.gmail.com>
Message-ID: <15412A37E8C9574393B24ADD991FAA760B899E093B@MERCMBX14.na.sas.com>

<lurking> You sort of said it yourself:  something along the lines of "if the natural comparison ordering violates comparable contract, the method _may_ throw IAE"?

Joel

-----Original Message-----
From: core-libs-dev-bounces at openjdk.java.net [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Martin Buchholz
Sent: Tuesday, July 07, 2009 12:34 PM
To: Christopher Hegarty -Sun Microsystems Ireland
Cc: core-libs-dev
Subject: Re: timsort

On Tue, Jul 7, 2009 at 08:57, Christopher Hegarty -Sun Microsystems
Ireland<Christopher.Hegarty at sun.com> wrote:
> Martin Buchholz wrote:
>>
>>
>> On Tue, Jul 7, 2009 at 07:35, Christopher Hegarty -Sun Microsystems
>> Ireland
>>
>>
>>
>>           2) With the addition of @throws IllegalArgumentException, this
>>             condition cannot be met with the old merge sort right, i.e.
>>        running
>>             with -Djava.util.Arrays.useLegacyMergeSort=true. So we're
>>        saying
>>             that all bets are off when running with this property set?
>>
>>
>>        No.  Please re-read the @throws IllegalArgumentException.
>>        It is carefully worded to make no promises at all.  All bets are
>>        off - period.
>>
>>    OK great. But just to clarify, what exactly does "if the natural
>>    order of the array elements is found to violate the Comparable
>>    contract" mean?
>>
>>
>> "natural order" is defined in the Comparable javadoc.
>
> Sorry, I still don't see how this @throws can be a no-op. Is it not possible
> to craft an array of Comparables that violates the Comparable contract and
> therefore provoke the sort method to throw IAE?

It is not feasible to check whether a particular implementation of Comparable
violates the Comparable contract - there are too many ways the contract
can be violated, and checking may be too expensive.

+     * @throws IllegalArgumentException if the natural order of the array
+     *         elements is found to violate the {@link Comparable} contract

So the proposed spec does not and cannot require any exception to be thrown.
What is proposed is *if* the implementation happens to check for violations
and if it chooses to throw an exception, then IAE is the exception type
that will be used.

Perhaps someone could come up with clearer wording than "is found to violate"?

Martin

> -Chris.
>>
>>  http://download.java.net/jdk7/docs/api/java/lang/Comparable.html
>>
>> We could use @linkplain to the Comparable spec, as elsewhere in java.util.
>>
>> Martin
>



From jjb at google.com  Tue Jul  7 16:47:17 2009
From: jjb at google.com (Joshua Bloch)
Date: Tue, 7 Jul 2009 09:47:17 -0700
Subject: timsort
In-Reply-To: <15412A37E8C9574393B24ADD991FAA760B899E093B@MERCMBX14.na.sas.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
	<1ccfd1c10907070420v17a72491je35246d61c510868@mail.gmail.com>
	<4A535D28.6090407@sun.com>
	<1ccfd1c10907070822n69299c4cjafb40a36615928b4@mail.gmail.com>
	<4A537051.2040803@sun.com>
	<1ccfd1c10907070933u5ba165a5qe1fe2a61a976f4b@mail.gmail.com>
	<15412A37E8C9574393B24ADD991FAA760B899E093B@MERCMBX14.na.sas.com>
Message-ID: <17b2302a0907070947x75943ec8md93d1f81e370278f@mail.gmail.com>

Joel,

Yep.  As a practical matter, it's likely to do so.  But consider the case of
a 1-element array: there's no way to test the transitivity and anti-symmetry
properties.  That's not the only case where the new implementation will fail
to detect a violation, but it's a clear proof that it is, in general,
impossible to do so.

   Josh

P.S.  I'm comfortable with the system property to select the legacy
implementation.

On Tue, Jul 7, 2009 at 9:44 AM, Joel Kamentz <Joel.Kamentz at sas.com> wrote:

> <lurking> You sort of said it yourself:  something along the lines of "if
> the natural comparison ordering violates comparable contract, the method
> _may_ throw IAE"?
>
> Joel
>
> -----Original Message-----
> From: core-libs-dev-bounces at openjdk.java.net [mailto:
> core-libs-dev-bounces at openjdk.java.net] On Behalf Of Martin Buchholz
> Sent: Tuesday, July 07, 2009 12:34 PM
> To: Christopher Hegarty -Sun Microsystems Ireland
> Cc: core-libs-dev
> Subject: Re: timsort
>
> On Tue, Jul 7, 2009 at 08:57, Christopher Hegarty -Sun Microsystems
> Ireland<Christopher.Hegarty at sun.com> wrote:
> > Martin Buchholz wrote:
> >>
> >>
> >> On Tue, Jul 7, 2009 at 07:35, Christopher Hegarty -Sun Microsystems
> >> Ireland
> >>
> >>
> >>
> >>           2) With the addition of @throws IllegalArgumentException, this
> >>             condition cannot be met with the old merge sort right, i.e.
> >>        running
> >>             with -Djava.util.Arrays.useLegacyMergeSort=true. So we're
> >>        saying
> >>             that all bets are off when running with this property set?
> >>
> >>
> >>        No.  Please re-read the @throws IllegalArgumentException.
> >>        It is carefully worded to make no promises at all.  All bets are
> >>        off - period.
> >>
> >>    OK great. But just to clarify, what exactly does "if the natural
> >>    order of the array elements is found to violate the Comparable
> >>    contract" mean?
> >>
> >>
> >> "natural order" is defined in the Comparable javadoc.
> >
> > Sorry, I still don't see how this @throws can be a no-op. Is it not
> possible
> > to craft an array of Comparables that violates the Comparable contract
> and
> > therefore provoke the sort method to throw IAE?
>
> It is not feasible to check whether a particular implementation of
> Comparable
> violates the Comparable contract - there are too many ways the contract
> can be violated, and checking may be too expensive.
>
> +     * @throws IllegalArgumentException if the natural order of the array
> +     *         elements is found to violate the {@link Comparable}
> contract
>
> So the proposed spec does not and cannot require any exception to be
> thrown.
> What is proposed is *if* the implementation happens to check for violations
> and if it chooses to throw an exception, then IAE is the exception type
> that will be used.
>
> Perhaps someone could come up with clearer wording than "is found to
> violate"?
>
> Martin
>
> > -Chris.
> >>
> >>  http://download.java.net/jdk7/docs/api/java/lang/Comparable.html
> >>
> >> We could use @linkplain to the Comparable spec, as elsewhere in
> java.util.
> >>
> >> Martin
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090707/883efcef/attachment.html>

From jjb at google.com  Tue Jul  7 16:59:16 2009
From: jjb at google.com (Joshua Bloch)
Date: Tue, 7 Jul 2009 09:59:16 -0700
Subject: timsort
In-Reply-To: <4A531ABC.6010805@sun.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
Message-ID: <17b2302a0907070959p6de8a919s638b456f0e445089@mail.gmail.com>

Chris,

On Tue, Jul 7, 2009 at 2:51 AM, Christopher Hegarty -Sun Microsystems
Ireland <Christopher.Hegarty at sun.com> wrote:

> Hi Martin,
>
> Sorry for joining the party late...
>
> I think adding the system property should take care of the compatibility
> issues, at least giving the user the ability to revert to the old behavior
> if they so choose.
>
> I have a few minor comments ( if these issue have been discussed already I
> apologize ):
>
> 1) Should we update the Arrays class description and appropriate sort
>   methods to now refer to timsort instead of saying: "The sorting
>   algorithm is a modified mergesort...". I know this is not strictly
>   necessary, but you must have considered it already, right?


No.  I totally missed it.  Good catch!


>
> 2) With the addition of @throws IllegalArgumentException, this
>   condition cannot be met with the old merge sort right, i.e. running
>   with -Djava.util.Arrays.useLegacyMergeSort=true. So we're saying
>   that all bets are off when running with this property set?


Others have already commented on this; this @throws clause makes no
promises, but calls out a (desirable) behavior that the new implementation
might exhibit (and the old one never will) when the user has violated a
fundamental contract (hence all bets are off).

          Josh

P.S.  Thanks all, and especially Martin, for shepherding this work into the
JDK!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090707/feb76705/attachment.html>

From Kumar.Srinivasan at Sun.COM  Tue Jul  7 18:25:52 2009
From: Kumar.Srinivasan at Sun.COM (Kumar Srinivasan)
Date: Tue, 07 Jul 2009 11:25:52 -0700
Subject: -classpath @FILE
In-Reply-To: <1ccfd1c10907061519y43474f4ckc3cda4be526e0c60@mail.gmail.com>
References: <1ccfd1c10907061417s6e3545d1j8cf05a0f108be01d@mail.gmail.com>
	<4A5275F8.60307@Sun.COM>
	<1ccfd1c10907061519y43474f4ckc3cda4be526e0c60@mail.gmail.com>
Message-ID: <4A539330.3040103@Sun.COM>

Martin,

CR: 4326573, I have updated this bug with your solution.

Danke
Kumar

> On Mon, Jul 6, 2009 at 15:08, Kumar Srinivasan<Kumar.Srinivasan at sun.com> wrote:
>   
>> Hi Martin,
>>
>> I take it you want me to integrate this after due diligence ?
>>     
>
> Yes.
> We are not in any hurry to integrate it,
> and we understand that there may need to be work done on
> this (like generalization/doc/test work) that Google might not
> want to do (or cannot, in the case of the man pages),
> so this change may reasonably remain unmerged.
> For the time being, it is useful for us.
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/classpath at FILE/
>
> Please file an RFE.
>
> Martin
>
>   
>> I can take a look at it, as a submission, but I can't promise when I will
>> be able to look into getting it into openjdk as my priorities are focused
>> elsewhere at this time.
>>
>> Thanks
>> Kumar
>>
>>     
>>> Hi launcher team,
>>>
>>> We have a local mod to openjdk's launcher here at Google
>>> that we would be willing to send upstream.
>>> We were hitting the 128kb command line arg limit
>>> (that is, the Linux limit on the size of *one* argument,
>>> not the entire command line) and made the simple expedient
>>> of allowing the classpath to be specified via a file,
>>> using the familiar
>>> -cp @FILE
>>> syntax.
>>>
>>> It's hard to create a uniform support for @FILE
>>> across all jdk commands, because the jar and javac
>>> commands already do their own @FILE parsing.
>>> So although -cp @FILE is a bit of a hack,
>>> it is useful enough that it probably should be part of the jdk.
>>> Remember that jdk engineers tend not to experience "jar hell"
>>> themselves.
>>>
>>> Martin
>>>
>>>       
>> --
>> Kumar Srinivasan           Sun Microsystems, Java Software.
>> 408-276-7586
>>
>>
>>     


-- 
Kumar Srinivasan           
Sun Microsystems, Java Software.
408-276-7586

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090707/991ca283/attachment.html>

From jjb at google.com  Tue Jul  7 19:02:52 2009
From: jjb at google.com (Joshua Bloch)
Date: Tue, 7 Jul 2009 12:02:52 -0700
Subject: timsort
In-Reply-To: <17b2302a0907070959p6de8a919s638b456f0e445089@mail.gmail.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
	<17b2302a0907070959p6de8a919s638b456f0e445089@mail.gmail.com>
Message-ID: <17b2302a0907071202h30e76db6l157818aedccd06c9@mail.gmail.com>

Chris,



>>
>> 1) Should we update the Arrays class description and appropriate sort
>>   methods to now refer to timsort instead of saying: "The sorting
>>   algorithm is a modified mergesort...". I know this is not strictly
>>   necessary, but you must have considered it already, right?
>
>
> No.  I totally missed it.  Good catch!
>
>

I propose this prose:

     * Implementation note: This implementation is a stable, adaptive,
iterative
     * mergesort that requires far fewer than n lg(n) comparisons when the
input
     * array is partially sorted, while offering the performance of a
traditional
     * mergesort when the input array is randomly ordered.  If the input
array is
     * nearly sorted, the implementation requires approximately n
comparisons.
     * Temporary storage requirements vary from a small constant for nearly
sorted
     * input arrays to n/2 object references for randomly ordered input
arrays.
     *
     * <p>The implementation takes equal advantage of ascending and
descending order
     * in its input array, and can take advantage of ascending and
descending order
     * in different parts of the the same input array.  It is well-suited to
     * merging two or more sorted arrays: simply concatenate the arrays and
sort
     * the resulting array.
     *
     * <p>The implementation was adapted from Tim Peters's list sort for
Python
     * (<a href="
http://svn.python.org/projects/python/trunk/Objects/listsort.txt">
     * TimSort</a>).  It uses techiques from Peter McIlroy's "Optimistic
Sorting
     * and Information Theoretic Complexity",in Proceedings of the Fourth
Annual
     * ACM-SIAM Symposium on Discrete Algorithms, pp 467-474, January 1993.

There are six methods that could use this prose, four in java.uti.Arrays,
and two in java.util.Collections.  Alternatively, the prose could be
included in one place, and linked to repeatedly.

            Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090707/f565409d/attachment.html>

From martinrb at google.com  Tue Jul  7 19:45:51 2009
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 7 Jul 2009 12:45:51 -0700
Subject: timsort
In-Reply-To: <17b2302a0907071202h30e76db6l157818aedccd06c9@mail.gmail.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
	<17b2302a0907070959p6de8a919s638b456f0e445089@mail.gmail.com>
	<17b2302a0907071202h30e76db6l157818aedccd06c9@mail.gmail.com>
Message-ID: <1ccfd1c10907071245uefa3237t5d933c3911c8b482@mail.gmail.com>

Josh,  thanks for the implementation notes.

I modified them by
- Peters's => Peters'
- added a space after a comma
- added a <p>
- refilled to fit into 80 cols.

I also did a bit of modernization of the javadoc for
the 6 related public sort methods.

I addressed the issue of insufficient clarity
for the optionality of IAE by using "(optional)"

+     * @throws IllegalArgumentException (optional) if the implementation
+     *         detects that the natural ordering of the list elements is
+     *         found to violate the {@link Comparable} contract


http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/

Chris, time to generate a blenderrev.
You should have one for CCC anyways.
I'll include it with my webrev.
The ball is in your court.

Martin


On Tue, Jul 7, 2009 at 12:02, Joshua Bloch <jjb at google.com> wrote:

> Chris,
>
>
>
>>>
>>> 1) Should we update the Arrays class description and appropriate sort
>>>   methods to now refer to timsort instead of saying: "The sorting
>>>   algorithm is a modified mergesort...". I know this is not strictly
>>>   necessary, but you must have considered it already, right?
>>
>>
>> No.  I totally missed it.  Good catch!
>>
>>
>
> I propose this prose:
>
>      * Implementation note: This implementation is a stable, adaptive,
> iterative
>      * mergesort that requires far fewer than n lg(n) comparisons when the
> input
>      * array is partially sorted, while offering the performance of a
> traditional
>      * mergesort when the input array is randomly ordered.  If the input
> array is
>      * nearly sorted, the implementation requires approximately n
> comparisons.
>      * Temporary storage requirements vary from a small constant for nearly
> sorted
>      * input arrays to n/2 object references for randomly ordered input
> arrays.
>      *
>      * <p>The implementation takes equal advantage of ascending and
> descending order
>      * in its input array, and can take advantage of ascending and
> descending order
>      * in different parts of the the same input array.  It is well-suited
> to
>      * merging two or more sorted arrays: simply concatenate the arrays and
> sort
>      * the resulting array.
>      *
>      * <p>The implementation was adapted from Tim Peters's list sort for
> Python
>      * (<a href="
> http://svn.python.org/projects/python/trunk/Objects/listsort.txt">
>      * TimSort</a>).  It uses techiques from Peter McIlroy's "Optimistic
> Sorting
>      * and Information Theoretic Complexity",in Proceedings of the Fourth
> Annual
>      * ACM-SIAM Symposium on Discrete Algorithms, pp 467-474, January 1993.
>
> There are six methods that could use this prose, four in java.uti.Arrays,
> and two in java.util.Collections.  Alternatively, the prose could be
> included in one place, and linked to repeatedly.
>
>             Josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090707/46047bdb/attachment.html>

From Christopher.Hegarty at Sun.COM  Tue Jul  7 20:28:28 2009
From: Christopher.Hegarty at Sun.COM (Christopher Hegarty -Sun Microsystems Ireland)
Date: Tue, 07 Jul 2009 21:28:28 +0100
Subject: timsort
In-Reply-To: <1ccfd1c10907071245uefa3237t5d933c3911c8b482@mail.gmail.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
	<17b2302a0907070959p6de8a919s638b456f0e445089@mail.gmail.com>
	<17b2302a0907071202h30e76db6l157818aedccd06c9@mail.gmail.com>
	<1ccfd1c10907071245uefa3237t5d933c3911c8b482@mail.gmail.com>
Message-ID: <4A53AFEC.9040803@sun.com>

Hi Martin, Josh,

Thank you both for making these changes.

Once we have the Blenderev I'll file a CCC request and keep you informed 
of its status.

Martin:
  I'm signing off for tonight. I can create the Blenderrev tomorrow if 
you don't get a chance. Also, I think you need an additional 'optional' 
for the final Arrays.sort method.

-Chris.

Martin Buchholz wrote:
> Josh,  thanks for the implementation notes.
> 
> I modified them by
> - Peters's => Peters'
> - added a space after a comma
> - added a <p>
> - refilled to fit into 80 cols.
> 
> I also did a bit of modernization of the javadoc for
> the 6 related public sort methods.
> 
> I addressed the issue of insufficient clarity
> for the optionality of IAE by using "(optional)"
> 
> +     * @throws IllegalArgumentException (optional) if the implementation
> 
> +     *         detects that the natural ordering of the list elements is
> +     *         found to violate the {@link Comparable} contract
> 
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/
> 
> Chris, time to generate a blenderrev.
> You should have one for CCC anyways.
> I'll include it with my webrev.
> The ball is in your court.
> 
> Martin
> 
> 
> On Tue, Jul 7, 2009 at 12:02, Joshua Bloch <jjb at google.com 
> <mailto:jjb at google.com>> wrote:
> 
>     Chris,
> 
> 
> 
> 
>             1) Should we update the Arrays class description and
>             appropriate sort
>               methods to now refer to timsort instead of saying: "The
>             sorting
>               algorithm is a modified mergesort...". I know this is not
>             strictly
>               necessary, but you must have considered it already, right?
> 
> 
>         No.  I totally missed it.  Good catch!
>          
> 
> 
>     I propose this prose:
> 
>          * Implementation note: This implementation is a stable,
>     adaptive, iterative
>          * mergesort that requires far fewer than n lg(n) comparisons
>     when the input
>          * array is partially sorted, while offering the performance of
>     a traditional
>          * mergesort when the input array is randomly ordered.  If the
>     input array is
>          * nearly sorted, the implementation requires approximately n
>     comparisons.
>          * Temporary storage requirements vary from a small constant for
>     nearly sorted
>          * input arrays to n/2 object references for randomly ordered
>     input arrays.
>          *
>          * <p>The implementation takes equal advantage of ascending and
>     descending order
>          * in its input array, and can take advantage of ascending and
>     descending order
>          * in different parts of the the same input array.  It is
>     well-suited to
>          * merging two or more sorted arrays: simply concatenate the
>     arrays and sort
>          * the resulting array.
>          *
>          * <p>The implementation was adapted from Tim Peters's list sort
>     for Python
>          * (<a
>     href="http://svn.python.org/projects/python/trunk/Objects/listsort.txt">
>          * TimSort</a>).  It uses techiques from Peter McIlroy's
>     "Optimistic Sorting
>          * and Information Theoretic Complexity",in Proceedings of the
>     Fourth Annual
>          * ACM-SIAM Symposium on Discrete Algorithms, pp 467-474,
>     January 1993.
> 
>     There are six methods that could use this prose, four in
>     java.uti.Arrays, and two in java.util.Collections.  Alternatively,
>     the prose could be included in one place, and linked to repeatedly.
> 
>                 Josh
> 
> 


From martinrb at google.com  Tue Jul  7 21:56:31 2009
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 7 Jul 2009 14:56:31 -0700
Subject: timsort
In-Reply-To: <4A53AFEC.9040803@sun.com>
References: <1ccfd1c10906291621v3a50fd2fid98c3aa14dddc8af@mail.gmail.com>
	<4A49E348.5090902@sun.com>
	<1ccfd1c10906300912u2250d0c5l819535e1ea4ffec4@mail.gmail.com>
	<4A4A5961.6070201@sun.com>
	<1ccfd1c10907061612v6c0e9079t1cc299cd4a49069e@mail.gmail.com>
	<4A531ABC.6010805@sun.com>
	<17b2302a0907070959p6de8a919s638b456f0e445089@mail.gmail.com>
	<17b2302a0907071202h30e76db6l157818aedccd06c9@mail.gmail.com>
	<1ccfd1c10907071245uefa3237t5d933c3911c8b482@mail.gmail.com>
	<4A53AFEC.9040803@sun.com>
Message-ID: <1ccfd1c10907071456u7dbc34b5h875f8db123527490@mail.gmail.com>

On Tue, Jul 7, 2009 at 13:28, Christopher Hegarty -Sun Microsystems Ireland
<Christopher.Hegarty at sun.com> wrote:

> Hi Martin, Josh,
>
> Thank you both for making these changes.
>
> Once we have the Blenderev I'll file a CCC request and keep you informed of
> its status.
>
> Martin:
>  I'm signing off for tonight. I can create the Blenderrev tomorrow if you
> don't get a chance. Also, I think you need an additional 'optional' for the
> final Arrays.sort method.
>

Good catch!  I did some final fixup of the IAE specs.

It's a cruel world.  Although I am the author of BlenderRev, I can't run it
myself
because it hasn't been open-sourced (and it has a third-party closed-source
dependency).  Y'all should set up a public BlenderRev server, that would
turn
a mercurial revision into a BlenderRev.
Open-sourcing my Sun ~/bin would be nice.

webrev regenerated.

Martin


>
> -Chris.
>
> Martin Buchholz wrote:
>
>> Josh,  thanks for the implementation notes.
>>
>> I modified them by
>> - Peters's => Peters'
>> - added a space after a comma
>> - added a <p>
>> - refilled to fit into 80 cols.
>>
>> I also did a bit of modernization of the javadoc for
>> the 6 related public sort methods.
>>
>> I addressed the issue of insufficient clarity
>> for the optionality of IAE by using "(optional)"
>>
>> +     * @throws IllegalArgumentException (optional) if the implementation
>>
>> +     *         detects that the natural ordering of the list elements is
>> +     *         found to violate the {@link Comparable} contract
>>
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/timsort/<http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/timsort/>
>>
>> Chris, time to generate a blenderrev.
>> You should have one for CCC anyways.
>> I'll include it with my webrev.
>> The ball is in your court.
>>
>> Martin
>>
>>
>> On Tue, Jul 7, 2009 at 12:02, Joshua Bloch <jjb at google.com <mailto:
>> jjb at google.com>> wrote:
>>
>>    Chris,
>>
>>
>>
>>
>>            1) Should we update the Arrays class description and
>>            appropriate sort
>>              methods to now refer to timsort instead of saying: "The
>>            sorting
>>              algorithm is a modified mergesort...". I know this is not
>>            strictly
>>              necessary, but you must have considered it already, right?
>>
>>
>>        No.  I totally missed it.  Good catch!
>>
>>
>>    I propose this prose:
>>
>>         * Implementation note: This implementation is a stable,
>>    adaptive, iterative
>>         * mergesort that requires far fewer than n lg(n) comparisons
>>    when the input
>>         * array is partially sorted, while offering the performance of
>>    a traditional
>>         * mergesort when the input array is randomly ordered.  If the
>>    input array is
>>         * nearly sorted, the implementation requires approximately n
>>    comparisons.
>>         * Temporary storage requirements vary from a small constant for
>>    nearly sorted
>>         * input arrays to n/2 object references for randomly ordered
>>    input arrays.
>>         *
>>         * <p>The implementation takes equal advantage of ascending and
>>    descending order
>>         * in its input array, and can take advantage of ascending and
>>    descending order
>>         * in different parts of the the same input array.  It is
>>    well-suited to
>>         * merging two or more sorted arrays: simply concatenate the
>>    arrays and sort
>>         * the resulting array.
>>         *
>>         * <p>The implementation was adapted from Tim Peters's list sort
>>    for Python
>>         * (<a
>>    href="http://svn.python.org/projects/python/trunk/Objects/listsort.txt
>> ">
>>         * TimSort</a>).  It uses techiques from Peter McIlroy's
>>    "Optimistic Sorting
>>         * and Information Theoretic Complexity",in Proceedings of the
>>    Fourth Annual
>>         * ACM-SIAM Symposium on Discrete Algorithms, pp 467-474,
>>    January 1993.
>>
>>    There are six methods that could use this prose, four in
>>    java.uti.Arrays, and two in java.util.Collections.  Alternatively,
>>    the prose could be included in one place, and linked to repeatedly.
>>
>>                Josh
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090707/7e735d9e/attachment.html>

From joe.darcy at sun.com  Tue Jul  7 23:21:31 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Tue, 07 Jul 2009 23:21:31 +0000
Subject: hg: jdk7/tl/jdk: 6857803: Missing links to exceptions in javadoc for
	Class.getGeneric{Superclass, Interfaces}
Message-ID: <20090707232208.A82A1ECE0@hg.openjdk.java.net>

Changeset: 0a294c066e7a
Author:    darcy
Date:      2009-07-07 16:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0a294c066e7a

6857803: Missing links to exceptions in javadoc for Class.getGeneric{Superclass, Interfaces}
Reviewed-by: chegar

! src/share/classes/java/lang/Class.java



From martinrb at google.com  Wed Jul  8 00:05:44 2009
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 7 Jul 2009 17:05:44 -0700
Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
In-Reply-To: <1247005849.13302.1323974975@webmail.messagingengine.com>
References: <1247005849.13302.1323974975@webmail.messagingengine.com>
Message-ID: <1ccfd1c10907071705x44599761lb972be4b470628b@mail.gmail.com>

[+core-libs-dev]

Doug Lea and I are (slowly) working on a new version of LinkedBlockingDeque.
I was not aware of a deadlock but can vaguely imagine how it might happen.
A small reproducible test case from you would be useful.

Unfinished work in progress can be found here:
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/BlockingQueue/

Martin

On Tue, Jul 7, 2009 at 15:30, Ariel Weisberg <ariel at weisberg.ws> wrote:

> Hi all,
>
> I did a search on LinkedBlockingDeque and didn't find anything similar
> to what I am seeing. Attached is the stack trace from an application
> that is deadlocked with three threads waiting for 0x00002aaab3e91080
> (threads "ExecutionSite: 26", "ExecutionSite:27", and "Network
> Selector"). The execution sites are attempting to offer results to the
> deque and the network thread is trying to poll for them using the
> non-blocking version of poll. I am seeing the network thread never
> return from poll (straight poll()). Do my eyes deceive me?
>
> Thanks,
>
> Ariel Weisberg
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090707/5854e79b/attachment.html>

From weijun.wang at sun.com  Wed Jul  8 04:13:26 2009
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Wed, 08 Jul 2009 04:13:26 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20090708041413.79C1FED07@hg.openjdk.java.net>

Changeset: 1175f872a968
Author:    weijun
Date:      2009-07-08 12:07 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1175f872a968

6857802: GSS getRemainingInitLifetime method returns milliseconds not seconds
Reviewed-by: xuelei

! src/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java
+ test/sun/security/krb5/auto/LifeTimeInSeconds.java

Changeset: 1df67a3ecce8
Author:    weijun
Date:      2009-07-08 12:07 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1df67a3ecce8

6857795: krb5.conf ignored if system properties on realm and kdc are provided
Reviewed-by: xuelei

! src/share/classes/sun/security/krb5/Config.java
+ test/sun/security/krb5/ConfPlusProp.java
+ test/sun/security/krb5/confplusprop.conf
+ test/sun/security/krb5/confplusprop2.conf



From neugens at limasoftware.net  Wed Jul  8 17:59:55 2009
From: neugens at limasoftware.net (Mario Torre)
Date: Wed, 08 Jul 2009 19:59:55 +0200
Subject: malloc failures in java/util/zip/Deflater
Message-ID: <4A54DE9B.7000807@limasoftware.net>

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


From kelly.ohair at sun.com  Wed Jul  8 18:08:39 2009
From: kelly.ohair at sun.com (kelly.ohair at sun.com)
Date: Wed, 08 Jul 2009 18:08:39 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20090708180936.1386CEDA0@hg.openjdk.java.net>

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

6855551: 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



From Roman.Kennke at Sun.COM  Wed Jul  8 18:52:31 2009
From: Roman.Kennke at Sun.COM (Roman Kennke)
Date: Wed, 08 Jul 2009 20:52:31 +0200
Subject: malloc failures in java/util/zip/Deflater
In-Reply-To: <4A54DE9B.7000807@limasoftware.net>
References: <4A54DE9B.7000807@limasoftware.net>
Message-ID: <1247079151.23160.21.camel@moonlight>

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




From neugens at limasoftware.net  Wed Jul  8 19:33:39 2009
From: neugens at limasoftware.net (Mario Torre)
Date: Wed, 08 Jul 2009 21:33:39 +0200
Subject: malloc failures in java/util/zip/Deflater
In-Reply-To: <1247079151.23160.21.camel@moonlight>
References: <4A54DE9B.7000807@limasoftware.net>
	<1247079151.23160.21.camel@moonlight>
Message-ID: <4A54F493.7010608@limasoftware.net>

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


From Roman.Kennke at Sun.COM  Wed Jul  8 20:01:46 2009
From: Roman.Kennke at Sun.COM (Roman Kennke)
Date: Wed, 08 Jul 2009 22:01:46 +0200
Subject: malloc failures in java/util/zip/Deflater
In-Reply-To: <4A54F493.7010608@limasoftware.net>
References: <4A54DE9B.7000807@limasoftware.net>
	<1247079151.23160.21.camel@moonlight>
	<4A54F493.7010608@limasoftware.net>
Message-ID: <1247083306.23160.25.camel@moonlight>

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




From martinrb at google.com  Wed Jul  8 22:15:44 2009
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 8 Jul 2009 15:15:44 -0700
Subject: ConcurrentLinkedQueue changes
Message-ID: <1ccfd1c10907081515p3295bd1bt5da81eb374892033@mail.gmail.com>

The long-awaited changes to ConcurrentLinkedQueue
have come out of vaporware status and are ready for
commit to openjdk7 soon.

When it comes to concurrent lock-free data structures,
even getting singly-linked lists right is really hard!

We do not need additional review according to openjdk rules,
but interested parties are invited to provide some.

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/CLQ/

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090708/667c4347/attachment.html>

From martinrb at google.com  Wed Jul  8 22:15:53 2009
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 8 Jul 2009 15:15:53 -0700
Subject: LinkedBlockingDeque and LinkedBlockingQueue
Message-ID: <1ccfd1c10907081515q46863430m3711a7d608f98ec0@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090708/90f85fa4/attachment.html>

From David.Holmes at Sun.COM  Wed Jul  8 23:48:10 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Thu, 09 Jul 2009 09:48:10 +1000
Subject: malloc failures in java/util/zip/Deflater
In-Reply-To: <4A54DE9B.7000807@limasoftware.net>
References: <4A54DE9B.7000807@limasoftware.net>
Message-ID: <4A55303A.10407@sun.com>

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


From Joe.Darcy at Sun.COM  Thu Jul  9 01:49:54 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Wed, 08 Jul 2009 18:49:54 -0700
Subject: Code review request for 6628737: Specification of wrapper class
	valueOf static factories should require caching
Message-ID: <4A554CC2.60507@sun.com>

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.java    2009-07-08 
18:38:11.000000000 -0700
+++ new/src/share/classes/java/lang/Byte.java    2009-07-08 
18:38:11.000000000 -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.java    2009-07-08 
18:38:13.000000000 -0700
+++ new/src/share/classes/java/lang/Character.java    2009-07-08 
18:38:13.000000000 -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;u0000'
+     * to '&#92;u007f'", inclusive, and may cache other values outside
+     * of this range.
+     *
      * @param  c a char value.
      * @return a <tt>Character</tt> instance representing <tt>c</tt>.
      * @since  1.5
--- old/src/share/classes/java/lang/Integer.java    2009-07-08 
18:38:14.000000000 -0700
+++ new/src/share/classes/java/lang/Integer.java    2009-07-08 
18:38:14.000000000 -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.java    2009-07-08 
18:38:16.000000000 -0700
+++ new/src/share/classes/java/lang/Long.java    2009-07-08 
18:38:16.000000000 -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 <em>not</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.java    2009-07-08 
18:38:17.000000000 -0700
+++ new/src/share/classes/java/lang/Short.java    2009-07-08 
18:38:17.000000000 -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


From mr at sun.com  Thu Jul  9 03:50:25 2009
From: mr at sun.com (Mark Reinhold)
Date: Wed, 08 Jul 2009 20:50:25 -0700
Subject: Code review request for 6628737: Specification of wrapper class
	valueOf static factories should require caching 
In-Reply-To: joe.darcy@sun.com; Wed, 08 Jul 2009 18:49:54 PDT;
	<4A554CC2.60507@sun.com> 
Message-ID: <20090709035025.47968A2BE@callebaut.niobe.net>

Looks fine to me.

Minor formatting nit in each delta except the first:

> ...
> 
> --- old/src/share/classes/java/lang/Character.java    2009-07-08
> 18:38:13.000000000 -0700
> +++ new/src/share/classes/java/lang/Character.java    2009-07-08
> 18:38:13.000000000 -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;u0000'
> +     * to '&#92;u007f'", inclusive, and may cache other values outside
> +     * of this range.
> +     *
>       * @param  c a char value.
>       * @return a <tt>Character</tt> instance representing <tt>c</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


From Kelly.Ohair at Sun.COM  Thu Jul  9 16:57:38 2009
From: Kelly.Ohair at Sun.COM (Kelly O'Hair)
Date: Thu, 09 Jul 2009 09:57:38 -0700
Subject: malloc failures in java/util/zip/Deflater
In-Reply-To: <4A55303A.10407@sun.com>
References: <4A54DE9B.7000807@limasoftware.net> <4A55303A.10407@sun.com>
Message-ID: <4A562182.6030200@sun.com>

I tend to agree.

Shouldn't a zero length entry be treated special, or disallowed?

-kto

David Holmes - Sun Microsystems wrote:
> 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


From Xueming.Shen at Sun.COM  Thu Jul  9 17:41:53 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Thu, 09 Jul 2009 10:41:53 -0700
Subject: malloc failures in java/util/zip/Deflater
In-Reply-To: <4A562182.6030200@sun.com>
References: <4A54DE9B.7000807@limasoftware.net> <4A55303A.10407@sun.com>
	<4A562182.6030200@sun.com>
Message-ID: <4A562BE1.9060701@sun.com>


Zero length entry should be allowed. This is a regression, the result of the
un-successful fix for 6728376:-(

The webrev for 6728376 is
http://cr.openjdk.java.net/~sherman/6728376/webrev

We have the same in Inflater as well. I will file a bug for it.

Thanks Mario for catching this.

Sherman

Kelly O'Hair wrote:
> I tend to agree.
>
> Shouldn't a zero length entry be treated special, or disallowed?
>
> -kto
>
> David Holmes - Sun Microsystems wrote:
>> 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



From ariel at weisberg.ws  Wed Jul  8 22:57:55 2009
From: ariel at weisberg.ws (Ariel Weisberg)
Date: Wed, 08 Jul 2009 18:57:55 -0400
Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
In-Reply-To: <NFBBKALFDCPFIDBNKAPCEEIDICAA.davidcholmes@aapt.net.au>
References: <NFBBKALFDCPFIDBNKAPCEEIDICAA.davidcholmes@aapt.net.au>
Message-ID: <1247093875.31776.1324114639@webmail.messagingengine.com>

Hi,

> The poll()ing thread is blocked waiting for the internal lock, but
> there's
> no indication of any thread owning that lock. You're using an OpenJDK 6
> build ... can you try JDK7 ?

I got a chance to do that today. I downloaded JDK 7 from
http://www.java.net/download/jdk7/binaries/jdk-7-ea-bin-b63-linux-x64-02_jul_2009.bin
and was able to reproduce the problem. I have attached the stack trace
from running the 1.7 version. It is the same situation as before except
there are 9 execution sites running on each host. There are no threads
that are missing or that have been restarted. Foo Network thread
(selector thread) and Network Thread - 0 are waiting on
0x00002aaab43d3b28. I also ran with JDK 7 and 6 and LinkedBlockingQueue
and was not able to recreate the problem using that structure.

> I don't recall anything similar to this, but I don't know what version
> that
> OpenJDK6 build relates to.

The cluster is running on CentOS 5.3.
>[aweisberg at 3f ~]$ rpm -qi java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5
>Name        : java-1.6.0-openjdk           Relocations: (not relocatable)
>Version     : 1.6.0.0                           Vendor: CentOS
>Release     : 0.30.b09.el5                  Build Date: Tue 07 Apr 2009 07:24:52 PM EDT
>Install Date: Thu 11 Jun 2009 03:27:46 PM EDT      Build Host: builder10.centos.org
>Group       : Development/Languages         Source RPM: java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5.src.rpm
>Size        : 76336266                         License: GPLv2 with exceptions
>Signature   : DSA/SHA1, Wed 08 Apr 2009 07:55:13 AM EDT, Key ID a8a447dce8562897
>URL         : http://icedtea.classpath.org/
>Summary     : OpenJDK Runtime Environment
>Description :
>The OpenJDK runtime environment.

> Make sure you haven't missed any exceptions occurring in other threads.
There are no threads missing in the application (terminated threads are
not replaced) and there is a try catch pair (prints error and rethrows)
around the run loop of each thread. It is possible that an exception may
have been swallowed up somewhere.

>A small reproducible test case from you would be useful.
I am working on that. I wrote a test case that mimics the application's
use of the LBD, but I have not succeeded in reproducing the problem in
the test case. The app has a single thread (network selector) that polls
the LBD and several threads (ExecutionSites, and network threads that
return results from remote ExecutionSites) that offer results into the
queue. About 120k items will go into/out of the deque each second. In
the actual app the problem is reproducible but inconsistent. If I run on
my dual core laptop I can't reproduce it, and it is less likely to occur
with a small cluster, but with 6 nodes (~560k transactions/sec) the
problem will usually appear. Sometimes the cluster will run for several
minutes without issue and other times it will deadlock immediately.

Thanks,

Ariel

On Wed, 08 Jul 2009 05:14 +1000, "Martin Buchholz"
<martinrb at google.com> wrote:
>[+core-libs-dev]
>
>Doug Lea and I are (slowly) working on a new version of LinkedBlockingDeque.
>I was not aware of a deadlock but can vaguely imagine how it might happen.
>A small reproducible test case from you would be useful.
>
>Unfinished work in progress can be found here:
>http://cr.openjdk.java.net/~martin/webrevs/openjdk7/BlockingQueue/
>
>Martin

On Wed, 08 Jul 2009 05:14 +1000, "David Holmes"
<davidcholmes at aapt.net.au> wrote:
> 
> Ariel,
> 
> The poll()ing thread is blocked waiting for the internal lock, but
> there's
> no indication of any thread owning that lock. You're using an OpenJDK 6
> build ... can you try JDK7 ?
> 
> I don't recall anything similar to this, but I don't know what version
> that
> OpenJDK6 build relates to.
> 
> Make sure you haven't missed any exceptions occurring in other threads.
> 
> David Holmes
> 
> > -----Original Message-----
> > From: concurrency-interest-bounces at cs.oswego.edu
> > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Ariel
> > Weisberg
> > Sent: Wednesday, 8 July 2009 8:31 AM
> > To: concurrency-interest at cs.oswego.edu
> > Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
> >
> >
> > Hi all,
> >
> > I did a search on LinkedBlockingDeque and didn't find anything similar
> > to what I am seeing. Attached is the stack trace from an application
> > that is deadlocked with three threads waiting for 0x00002aaab3e91080
> > (threads "ExecutionSite: 26", "ExecutionSite:27", and "Network
> > Selector"). The execution sites are attempting to offer results to the
> > deque and the network thread is trying to poll for them using the
> > non-blocking version of poll. I am seeing the network thread never
> > return from poll (straight poll()). Do my eyes deceive me?
> >
> > Thanks,
> >
> > Ariel Weisberg
> >
> 


From jon.vanalten at redhat.com  Thu Jul  9 15:04:13 2009
From: jon.vanalten at redhat.com (Jon VanAlten)
Date: Thu, 9 Jul 2009 11:04:13 -0400 (EDT)
Subject: patch to address sun bug 6562614
Message-ID: <591643195.301921247151853377.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>

Hi,

I've put up a webrev at http://icedtea.classpath.org/~vanaltj/webrevs/tl/patch1/index.html to address http://bugs.sun.com/view_bug.do?bug_id=6562614, also referenced on Icedtea bugzilla as http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=289 .  Comments?  Concerns?  If this is an okay patch I will require someone to push for me as I do not have commit privilege.

Thanks,

jon


From gnu_andrew at member.fsf.org  Thu Jul  9 19:01:59 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 9 Jul 2009 20:01:59 +0100
Subject: patch to address sun bug 6562614
In-Reply-To: <591643195.301921247151853377.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
References: <591643195.301921247151853377.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <17c6771e0907091201u503fa03aibb881681e3a8cf2@mail.gmail.com>

2009/7/9 Jon VanAlten <jon.vanalten at redhat.com>:
> Hi,
>
> I've put up a webrev at http://icedtea.classpath.org/~vanaltj/webrevs/tl/patch1/index.html to address http://bugs.sun.com/view_bug.do?bug_id=6562614, also referenced on Icedtea bugzilla as http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=289 . ?Comments? ?Concerns? ?If this is an okay patch I will require someone to push for me as I do not have commit privilege.
>
> Thanks,
>
> jon
>

This is a simple cleanup patch which was discussed, and I believe
Martin approved, here:

http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-July/006427.html

If Jon's webrev looks ok, I'll be happy to do the actual push to the tl forest.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Joe.Darcy at Sun.COM  Thu Jul  9 19:22:53 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 09 Jul 2009 12:22:53 -0700
Subject: Code review request for 6628737: Specification of wrapper class
	valueOf static factories should require caching
In-Reply-To: <20090709035025.47968A2BE@callebaut.niobe.net>
References: <20090709035025.47968A2BE@callebaut.niobe.net>
Message-ID: <4A56438D.8020708@sun.com>

Mark Reinhold wrote:
> Looks fine to me.
>
> Minor formatting nit in each delta except the first:
>
>   
>> ...
>>
>> --- old/src/share/classes/java/lang/Character.java    2009-07-08
>> 18:38:13.000000000 -0700
>> +++ new/src/share/classes/java/lang/Character.java    2009-07-08
>> 18:38:13.000000000 -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;u0000'
>> +     * to '&#92;u007f'", inclusive, and may cache other values outside
>> +     * of this range.
>> +     *
>>       * @param  c a char value.
>>       * @return a <tt>Character</tt> instance representing <tt>c</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>.
>
>   

Actually the extra blanks lines in only the javadoc were intentional; I 
sometimes like to insert extra lines in the javadoc to make it easier to 
read and secondarily to reduce the creation of spurious diffs from 
javadoc reformatting.

Thanks for the review,

-Joe


From joe.darcy at sun.com  Thu Jul  9 19:39:26 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Thu, 09 Jul 2009 19:39:26 +0000
Subject: hg: jdk7/tl/jdk: 6628737: Specification of wrapper class valueOf
	static factories should require caching
Message-ID: <20090709194005.A000EEDF0@hg.openjdk.java.net>

Changeset: ae60bb671e54
Author:    darcy
Date:      2009-07-09 12:31 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ae60bb671e54

6628737: Specification of wrapper class valueOf static factories should require caching
Reviewed-by: mr

! src/share/classes/java/lang/Byte.java
! src/share/classes/java/lang/Character.java
! src/share/classes/java/lang/Integer.java
! src/share/classes/java/lang/Long.java
! src/share/classes/java/lang/Short.java



From neugens at limasoftware.net  Thu Jul  9 20:09:08 2009
From: neugens at limasoftware.net (Mario Torre)
Date: Thu, 09 Jul 2009 22:09:08 +0200
Subject: malloc failures in java/util/zip/Deflater
In-Reply-To: <4A562182.6030200@sun.com>
References: <4A54DE9B.7000807@limasoftware.net> <4A55303A.10407@sun.com>
	<4A562182.6030200@sun.com>
Message-ID: <4A564E64.2020201@limasoftware.net>

Il 09/07/2009 18:57, Kelly O'Hair ha scritto:
> I tend to agree.
>
> Shouldn't a zero length entry be treated special, or disallowed?
>
> -kto

Hi Kelly,

Maybe I misunderstood the code, because I didn't went into it in so 
great details, but I think that the zero length is already considered 
special because it signals the end of the stream, and the variable 
"finished" is hence set in the code.

I'll spend some more time on that, and tell you. In the meantime, to 
test it, what I did was something like:

if (len == 0) {
   in_buf = NULL;

} else {
   in_buf = malloc(len); // len == 0
}

if (in_buf == 0 && len > 0) {
     /* throw the exception */
}

and it worked without crashing :)

Cheers,
Mario


From neugens at limasoftware.net  Thu Jul  9 20:17:53 2009
From: neugens at limasoftware.net (Mario Torre)
Date: Thu, 09 Jul 2009 22:17:53 +0200
Subject: malloc failures in java/util/zip/Deflater
In-Reply-To: <4A562BE1.9060701@sun.com>
References: <4A54DE9B.7000807@limasoftware.net>
	<4A55303A.10407@sun.com>	<4A562182.6030200@sun.com>
	<4A562BE1.9060701@sun.com>
Message-ID: <4A565071.1000904@limasoftware.net>

Il 09/07/2009 19:41, Xueming Shen ha scritto:
>
> Zero length entry should be allowed. This is a regression, the result of
> the
> un-successful fix for 6728376:-(
>
> The webrev for 6728376 is
> http://cr.openjdk.java.net/~sherman/6728376/webrev
>
> We have the same in Inflater as well. I will file a bug for it.
>
> Thanks Mario for catching this.
>
> Sherman

Hi!

Actually in my code I also spotted the same issue, as we got an endless 
loop there, but we use a slightly older OpenJDK code base.

Maybe that my fix is not complete, I would like to be alerted when the 
bug gets filed, is it possible?

Mario


From martinrb at google.com  Thu Jul  9 21:07:52 2009
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 9 Jul 2009 14:07:52 -0700
Subject: execvpe and glibc 2.10
Message-ID: <1ccfd1c10907091407q1557c49s6338614925808a23@mail.gmail.com>

Sorry, I should never have named a function (not even a static one)
'execvpe'.  It's amusing that I broke myself by requesting that glibc
implement 'execvpe'.

Here's the webrev:

http://cr.openjdk.java.net/~martin/webrevs/openjdk7/rename-execvpe/

For those following things, there are now 3 pending patches for
UNIXProcess_md.c:

rename-execvpe
vfork-exec
RESTARTABLE

and there are more to come.

Martin

On Thu, Jul 9, 2009 at 12:32, Lillian Angel <langel at redhat.com> wrote:

> Hi Martin,
>
> I am having trouble building IcedTea6 on Fedora 12 (
> http://koji.fedoraproject.org/koji/getfile?taskID=1463798&name=build.log),
> it seems because this bug was fixed in glibc-2.10-3:
> http://sourceware.org/bugzilla/show_bug.cgi?id=10221
>
> Do you have a patch for IcedTea/OpenJDK to get around this?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090709/7da5d9fc/attachment.html>

From martinrb at google.com  Thu Jul  9 22:39:47 2009
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 9 Jul 2009 15:39:47 -0700
Subject: Miscellaneous improvements to "jar".
In-Reply-To: <1ccfd1c10907061358w4815ce4by4145522e1c12edee@mail.gmail.com>
References: <1ccfd1c10906241934i21247553w685cf0b0b4cbd7b2@mail.gmail.com>
	<1ccfd1c10906251200n3bd78beek400abb51adcece40@mail.gmail.com>
	<1ccfd1c10906251757y72ccaca1l289dfc79f18b002c@mail.gmail.com>
	<4A450656.7070008@sun.com>
	<1ccfd1c10906270956g6c2f6208ne31f511ebcfaa41a@mail.gmail.com>
	<4A48555E.10900@sun.com>
	<1ccfd1c10907061358w4815ce4by4145522e1c12edee@mail.gmail.com>
Message-ID: <1ccfd1c10907091539p5fe80764if01bccda7efde6ac@mail.gmail.com>

Alright, I am all done with "jar" improvements.
(although the jar command is still far from perfect)
All the fixes (in particular, to make "jar" faster)
are in openjdk7 and openjdk6.

Martin

On Mon, Jul 6, 2009 at 13:58, Martin Buchholz <martinrb at google.com> wrote:

> I will atone for my use of nio2
> by providing the backport to openjdk6.
>
> 6854795: Miscellaneous improvements to "jar"
> 6834805: Improve jar -C performance
> 6332094: "jar t" and "jar x" should use ZipFile, not ZipInputStream
> 6496274: jar seems to use more CPU than it should
> Summary: backport jdk7 jar command (remove use of nio2)
>
> Assuming darcy and sherman agree,
> I will commit this to openjdk6.
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk6/jar-misc-6/<http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk6/jar-misc-6/>
>
> Martin
>
> On Sun, Jun 28, 2009 at 22:47, Xueming Shen<Xueming.Shen at sun.com> wrote:
> > (2)nio2 APIs are good, but now I can't not just copy/paste the jar Main
> to
> > 6.x:-)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090709/07a21015/attachment.html>

From Joe.Darcy at Sun.COM  Thu Jul  9 22:42:06 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 09 Jul 2009 15:42:06 -0700
Subject: Miscellaneous improvements to "jar".
In-Reply-To: <1ccfd1c10907091539p5fe80764if01bccda7efde6ac@mail.gmail.com>
References: <1ccfd1c10906241934i21247553w685cf0b0b4cbd7b2@mail.gmail.com>
	<1ccfd1c10906251200n3bd78beek400abb51adcece40@mail.gmail.com>
	<1ccfd1c10906251757y72ccaca1l289dfc79f18b002c@mail.gmail.com>
	<4A450656.7070008@sun.com>
	<1ccfd1c10906270956g6c2f6208ne31f511ebcfaa41a@mail.gmail.com>
	<4A48555E.10900@sun.com>
	<1ccfd1c10907061358w4815ce4by4145522e1c12edee@mail.gmail.com>
	<1ccfd1c10907091539p5fe80764if01bccda7efde6ac@mail.gmail.com>
Message-ID: <4A56723E.9080607@sun.com>

Thanks Martin!

-Joe


Martin Buchholz wrote:
> Alright, I am all done with "jar" improvements.
> (although the jar command is still far from perfect)
> All the fixes (in particular, to make "jar" faster)
> are in openjdk7 and openjdk6.
>
> Martin
>
> On Mon, Jul 6, 2009 at 13:58, Martin Buchholz <martinrb at google.com 
> <mailto:martinrb at google.com>> wrote:
>
>     I will atone for my use of nio2
>     by providing the backport to openjdk6.
>
>     6854795: Miscellaneous improvements to "jar"
>     6834805: Improve jar -C performance
>     6332094: "jar t" and "jar x" should use ZipFile, not ZipInputStream
>     6496274: jar seems to use more CPU than it should
>     Summary: backport jdk7 jar command (remove use of nio2)
>
>     Assuming darcy and sherman agree,
>     I will commit this to openjdk6.
>
>     http://cr.openjdk.java.net/~martin/webrevs/openjdk6/jar-misc-6/
>     <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk6/jar-misc-6/>
>
>     Martin
>
>     On Sun, Jun 28, 2009 at 22:47, Xueming Shen<Xueming.Shen at sun.com
>     <mailto:Xueming.Shen at sun.com>> wrote:
>     > (2)nio2 APIs are good, but now I can't not just copy/paste the
>     jar Main to
>     > 6.x:-)
>
>



From Joe.Darcy at Sun.COM  Thu Jul  9 22:47:24 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 09 Jul 2009 15:47:24 -0700
Subject: Code review request for 6857789: (reflect) Create common superclass
	of reflective exceptions
Message-ID: <4A56737C.50102@sun.com>

Hello.

Please review the patch below to fix

    6857789:  (reflect) Create common superclass of reflective exceptions

Half a dozen checked exceptions thrown by methods in core reflection 
don't have a superclass more specific than Exception, requiring multiple 
catch blocks around code using core reflection operations.    The fix is 
to change the direct superclass of the checked exceptions in question to 
a new shared checked exception, java.lang.ReflectiveOperationException.  
This is useful whether or not multi-catch is added as a language change 
in JDK 7.

Inserting a new level into the superclass hierarchy is a binary 
compatible change (JLSv3 Chapter 13); the change should be transparent 
other than to reflective operations that specifically queried the 
superclass.   All the exception classes in question already have 
explicit serialVersionUID fields so changing the superclass will be 
compatible from a serialization perspective too.

(A ccc request for this change is in progress too.)

Thanks,

-Joe


--- old/src/share/classes/java/lang/ClassNotFoundException.java    
2009-07-09 14:38:05.000000000 -0700
+++ new/src/share/classes/java/lang/ClassNotFoundException.java    
2009-07-09 14:38:05.000000000 -0700
@@ -50,7 +50,7 @@
  * @see     java.lang.ClassLoader#loadClass(java.lang.String, boolean)
  * @since   JDK1.0
  */
-public class ClassNotFoundException extends Exception {
+public class ClassNotFoundException extends ReflectiveOperationException {
     /**
      * use serialVersionUID from JDK 1.1.X for interoperability
      */
--- old/src/share/classes/java/lang/IllegalAccessException.java    
2009-07-09 14:38:06.000000000 -0700
+++ new/src/share/classes/java/lang/IllegalAccessException.java    
2009-07-09 14:38:06.000000000 -0700
@@ -56,7 +56,7 @@
  * @see     java.lang.reflect.Constructor#newInstance(Object[])
  * @since   JDK1.0
  */
-public class IllegalAccessException extends Exception {
+public class IllegalAccessException extends ReflectiveOperationException {
     private static final long serialVersionUID = 6616958222490762034L;
 
     /**
--- old/src/share/classes/java/lang/InstantiationException.java    
2009-07-09 14:38:06.000000000 -0700
+++ new/src/share/classes/java/lang/InstantiationException.java    
2009-07-09 14:38:06.000000000 -0700
@@ -43,7 +43,7 @@
  * @since   JDK1.0
  */
 public
-class InstantiationException extends Exception {
+class InstantiationException extends ReflectiveOperationException {
     private static final long serialVersionUID = -8441929162975509110L;
 
     /**
--- old/src/share/classes/java/lang/NoSuchFieldException.java    
2009-07-09 14:38:07.000000000 -0700
+++ new/src/share/classes/java/lang/NoSuchFieldException.java    
2009-07-09 14:38:07.000000000 -0700
@@ -31,7 +31,7 @@
  * @author  unascribed
  * @since   JDK1.1
  */
-public class NoSuchFieldException extends Exception {
+public class NoSuchFieldException extends ReflectiveOperationException {
     private static final long serialVersionUID = -6143714805279938260L;
 
     /**
--- old/src/share/classes/java/lang/NoSuchMethodException.java    
2009-07-09 14:38:08.000000000 -0700
+++ new/src/share/classes/java/lang/NoSuchMethodException.java    
2009-07-09 14:38:07.000000000 -0700
@@ -32,7 +32,7 @@
  * @since      JDK1.0
  */
 public
-class NoSuchMethodException extends Exception {
+class NoSuchMethodException extends ReflectiveOperationException {
     private static final long serialVersionUID = 5034388446362600923L;
 
     /**
--- 
old/src/share/classes/java/lang/reflect/InvocationTargetException.java    
2009-07-09 14:38:08.000000000 -0700
+++ 
new/src/share/classes/java/lang/reflect/InvocationTargetException.java    
2009-07-09 14:38:08.000000000 -0700
@@ -39,7 +39,7 @@
  * @see Method
  * @see Constructor
  */
-public class InvocationTargetException extends Exception {
+public class InvocationTargetException extends 
ReflectiveOperationException {
     /**
      * Use serialVersionUID from JDK 1.1.X for interoperability
      */
--- /dev/null    2009-07-06 20:02:10.000000000 -0700
+++ new/src/share/classes/java/lang/ReflectiveOperationException.java    
2009-07-09 14:38:09.000000000 -0700
@@ -0,0 +1,88 @@
+/*
+ * Copyright 2009 Sun Microsystems, Inc.  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.  Sun designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Sun in the LICENSE file that accompanied this code.
+ *
+ * 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 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
+ * CA 95054 USA or visit www.sun.com if you need additional information or
+ * have any questions.
+ */
+
+package java.lang;
+
+/**
+ * Common superclass of exceptions thrown by reflective operations in
+ * core reflection.
+ *
+ * @since 1.7
+ */
+public class ReflectiveOperationException extends Exception {
+    static final long serialVersionUID = 123456789L;
+
+    /**
+     * Conqstructs a new exception with {@code null} as its detail
+     * message.  The cause is not initialized, and may subsequently be
+     * initialized by a call to {@link #initCause}.
+     */
+    public ReflectiveOperationException() {
+        super();
+    }
+
+    /**
+     * Constructs a new exception with the specified detail message.
+     * The cause is not initialized, and may subsequently be
+     * initialized by a call to {@link #initCause}.
+     *
+     * @param   message   the detail message. The detail message is 
saved for
+     *          later retrieval by the {@link #getMessage()} method.
+     */
+    public ReflectiveOperationException(String message) {
+        super(message);
+    }
+
+    /**
+     * Constructs a new exception with the specified detail message
+     * and cause.  <p>Note that the detail message associated with
+     * {@code cause} is <em>not</em> automatically incorporated in
+     * this exception's detail message.
+     *
+     * @param  message the detail message (which is saved for later 
retrieval
+     *         by the {@link #getMessage()} method).
+     * @param  cause the cause (which is saved for later retrieval by the
+     *         {@link #getCause()} method).  (A {@code null} value is
+     *         permitted, and indicates that the cause is nonexistent or
+     *         unknown.)
+     */
+    public ReflectiveOperationException(String message, Throwable cause) {
+        super(message, cause);
+    }
+
+    /**
+     * Constructs a new exception with the specified cause and a detail
+     * message of {@code (cause==null ? null : cause.toString())} (which
+     * typically contains the class and detail message of {@code cause}).
+     *
+     * @param  cause the cause (which is saved for later retrieval by the
+     *         {@link #getCause()} method).  (A {@code null} value is
+     *         permitted, and indicates that the cause is nonexistent or
+     *         unknown.)
+     */
+    public ReflectiveOperationException(Throwable cause) {
+        super(cause);
+    }
+}




From martinrb at google.com  Thu Jul  9 23:16:59 2009
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 9 Jul 2009 16:16:59 -0700
Subject: Code review request for 6857789: (reflect) Create common 
	superclass of reflective exceptions
In-Reply-To: <4A56737C.50102@sun.com>
References: <4A56737C.50102@sun.com>
Message-ID: <1ccfd1c10907091616m39b547cbqab72cec466b67900@mail.gmail.com>

Thanks for this; I had a chance to use it in the past week,
if it had been there.

-----
typo

+     * Conqstructs a new exception with {@code null} as its detail

-----
Start paragraphs on new lines.

+     * and cause.  <p>Note that the detail message associated with
-----
Otherwise, looks good!

Martin

On Thu, Jul 9, 2009 at 15:47, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:

> Hello.
>
> Please review the patch below to fix
>
>   6857789:  (reflect) Create common superclass of reflective exceptions
>
> Half a dozen checked exceptions thrown by methods in core reflection don't
> have a superclass more specific than Exception, requiring multiple catch
> blocks around code using core reflection operations.    The fix is to change
> the direct superclass of the checked exceptions in question to a new shared
> checked exception, java.lang.ReflectiveOperationException.  This is useful
> whether or not multi-catch is added as a language change in JDK 7.
>
> Inserting a new level into the superclass hierarchy is a binary compatible
> change (JLSv3 Chapter 13); the change should be transparent other than to
> reflective operations that specifically queried the superclass.   All the
> exception classes in question already have explicit serialVersionUID fields
> so changing the superclass will be compatible from a serialization
> perspective too.
>
> (A ccc request for this change is in progress too.)
>
> Thanks,
>
> -Joe
>
>
> --- old/src/share/classes/java/lang/ClassNotFoundException.java
>  2009-07-09 14:38:05.000000000 -0700
> +++ new/src/share/classes/java/lang/ClassNotFoundException.java
>  2009-07-09 14:38:05.000000000 -0700
> @@ -50,7 +50,7 @@
>  * @see     java.lang.ClassLoader#loadClass(java.lang.String, boolean)
>  * @since   JDK1.0
>  */
> -public class ClassNotFoundException extends Exception {
> +public class ClassNotFoundException extends ReflectiveOperationException {
>    /**
>     * use serialVersionUID from JDK 1.1.X for interoperability
>     */
> --- old/src/share/classes/java/lang/IllegalAccessException.java
>  2009-07-09 14:38:06.000000000 -0700
> +++ new/src/share/classes/java/lang/IllegalAccessException.java
>  2009-07-09 14:38:06.000000000 -0700
> @@ -56,7 +56,7 @@
>  * @see     java.lang.reflect.Constructor#newInstance(Object[])
>  * @since   JDK1.0
>  */
> -public class IllegalAccessException extends Exception {
> +public class IllegalAccessException extends ReflectiveOperationException {
>    private static final long serialVersionUID = 6616958222490762034L;
>
>    /**
> --- old/src/share/classes/java/lang/InstantiationException.java
>  2009-07-09 14:38:06.000000000 -0700
> +++ new/src/share/classes/java/lang/InstantiationException.java
>  2009-07-09 14:38:06.000000000 -0700
> @@ -43,7 +43,7 @@
>  * @since   JDK1.0
>  */
> public
> -class InstantiationException extends Exception {
> +class InstantiationException extends ReflectiveOperationException {
>    private static final long serialVersionUID = -8441929162975509110L;
>
>    /**
> --- old/src/share/classes/java/lang/NoSuchFieldException.java    2009-07-09
> 14:38:07.000000000 -0700
> +++ new/src/share/classes/java/lang/NoSuchFieldException.java    2009-07-09
> 14:38:07.000000000 -0700
> @@ -31,7 +31,7 @@
>  * @author  unascribed
>  * @since   JDK1.1
>  */
> -public class NoSuchFieldException extends Exception {
> +public class NoSuchFieldException extends ReflectiveOperationException {
>    private static final long serialVersionUID = -6143714805279938260L;
>
>    /**
> --- old/src/share/classes/java/lang/NoSuchMethodException.java
>  2009-07-09 14:38:08.000000000 -0700
> +++ new/src/share/classes/java/lang/NoSuchMethodException.java
>  2009-07-09 14:38:07.000000000 -0700
> @@ -32,7 +32,7 @@
>  * @since      JDK1.0
>  */
> public
> -class NoSuchMethodException extends Exception {
> +class NoSuchMethodException extends ReflectiveOperationException {
>    private static final long serialVersionUID = 5034388446362600923L;
>
>    /**
> --- old/src/share/classes/java/lang/reflect/InvocationTargetException.java
>    2009-07-09 14:38:08.000000000 -0700
> +++ new/src/share/classes/java/lang/reflect/InvocationTargetException.java
>    2009-07-09 14:38:08.000000000 -0700
> @@ -39,7 +39,7 @@
>  * @see Method
>  * @see Constructor
>  */
> -public class InvocationTargetException extends Exception {
> +public class InvocationTargetException extends
> ReflectiveOperationException {
>    /**
>     * Use serialVersionUID from JDK 1.1.X for interoperability
>     */
> --- /dev/null    2009-07-06 20:02:10.000000000 -0700
> +++ new/src/share/classes/java/lang/ReflectiveOperationException.java
>  2009-07-09 14:38:09.000000000 -0700
> @@ -0,0 +1,88 @@
> +/*
> + * Copyright 2009 Sun Microsystems, Inc.  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.  Sun designates this
> + * particular file as subject to the "Classpath" exception as provided
> + * by Sun in the LICENSE file that accompanied this code.
> + *
> + * 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 Sun Microsystems, Inc., 4150 Network Circle, Santa
> Clara,
> + * CA 95054 USA or visit www.sun.com if you need additional information
> or
> + * have any questions.
> + */
> +
> +package java.lang;
> +
> +/**
> + * Common superclass of exceptions thrown by reflective operations in
> + * core reflection.
> + *
> + * @since 1.7
> + */
> +public class ReflectiveOperationException extends Exception {
> +    static final long serialVersionUID = 123456789L;
> +
> +    /**
> +     * Conqstructs a new exception with {@code null} as its detail
> +     * message.  The cause is not initialized, and may subsequently be
> +     * initialized by a call to {@link #initCause}.
> +     */
> +    public ReflectiveOperationException() {
> +        super();
> +    }
> +
> +    /**
> +     * Constructs a new exception with the specified detail message.
> +     * The cause is not initialized, and may subsequently be
> +     * initialized by a call to {@link #initCause}.
> +     *
> +     * @param   message   the detail message. The detail message is saved
> for
> +     *          later retrieval by the {@link #getMessage()} method.
> +     */
> +    public ReflectiveOperationException(String message) {
> +        super(message);
> +    }
> +
> +    /**
> +     * Constructs a new exception with the specified detail message
> +     * and cause.  <p>Note that the detail message associated with
> +     * {@code cause} is <em>not</em> automatically incorporated in
> +     * this exception's detail message.
> +     *
> +     * @param  message the detail message (which is saved for later
> retrieval
> +     *         by the {@link #getMessage()} method).
> +     * @param  cause the cause (which is saved for later retrieval by the
> +     *         {@link #getCause()} method).  (A {@code null} value is
> +     *         permitted, and indicates that the cause is nonexistent or
> +     *         unknown.)
> +     */
> +    public ReflectiveOperationException(String message, Throwable cause) {
> +        super(message, cause);
> +    }
> +
> +    /**
> +     * Constructs a new exception with the specified cause and a detail
> +     * message of {@code (cause==null ? null : cause.toString())} (which
> +     * typically contains the class and detail message of {@code cause}).
> +     *
> +     * @param  cause the cause (which is saved for later retrieval by the
> +     *         {@link #getCause()} method).  (A {@code null} value is
> +     *         permitted, and indicates that the cause is nonexistent or
> +     *         unknown.)
> +     */
> +    public ReflectiveOperationException(Throwable cause) {
> +        super(cause);
> +    }
> +}
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090709/9184ff61/attachment.html>

From forax at univ-mlv.fr  Fri Jul 10 00:48:41 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 10 Jul 2009 02:48:41 +0200
Subject: Code review request for 6857789: (reflect) Create common
	superclass of reflective exceptions
In-Reply-To: <1ccfd1c10907091616m39b547cbqab72cec466b67900@mail.gmail.com>
References: <4A56737C.50102@sun.com>
	<1ccfd1c10907091616m39b547cbqab72cec466b67900@mail.gmail.com>
Message-ID: <4A568FE9.80800@univ-mlv.fr>

This request seems dangerous,
InvocationTargetException should not be retrofitted because
usually its catch block is different from the others.
As is, this patch will introduce more burden than it tries to revolve.

Let me try to explain, all other exceptions can be avoided by checking 
modifiers,
knowing that the class exists in the bundle, etc but 
InvocationTargetException
means that the method/constructor raises an error (checked or not)
and we have no way to predict if this exception will be thrown or not.
Sothe catch block is very specific, it does something
like re-throwing uncheked exception, manages checked exceptions
declared in the signature of the method and wrap in 
UndeclaredThrowableException
checked exception that should not occurs.

John Rose recently proposes on coin-dev list a method that can be included
in the JDK, see
http://mail.openjdk.java.net/pipermail/coin-dev/2009-June/001954.html
to simplify catch blocks that catch an InvocationTargetException.

R?mi


Martin Buchholz a ?crit :
> Thanks for this; I had a chance to use it in the past week,
> if it had been there.
>
> -----
> typo
>
> +     * Conqstructs a new exception with {@code null} as its detail
>
> -----
> Start paragraphs on new lines.
>
> +     * and cause.  <p>Note that the detail message associated with
> -----
> Otherwise, looks good!
>
> Martin
>
> On Thu, Jul 9, 2009 at 15:47, Joseph D. Darcy <Joe.Darcy at sun.com 
> <mailto:Joe.Darcy at sun.com>> wrote:
>
>     Hello.
>
>     Please review the patch below to fix
>
>       6857789:  (reflect) Create common superclass of reflective
>     exceptions
>
>     Half a dozen checked exceptions thrown by methods in core
>     reflection don't have a superclass more specific than Exception,
>     requiring multiple catch blocks around code using core reflection
>     operations.    The fix is to change the direct superclass of the
>     checked exceptions in question to a new shared checked exception,
>     java.lang.ReflectiveOperationException.  This is useful whether or
>     not multi-catch is added as a language change in JDK 7.
>
>     Inserting a new level into the superclass hierarchy is a binary
>     compatible change (JLSv3 Chapter 13); the change should be
>     transparent other than to reflective operations that specifically
>     queried the superclass.   All the exception classes in question
>     already have explicit serialVersionUID fields so changing the
>     superclass will be compatible from a serialization perspective too.
>
>     (A ccc request for this change is in progress too.)
>
>     Thanks,
>
>     -Joe
>
>
>     --- old/src/share/classes/java/lang/ClassNotFoundException.java  
>      2009-07-09 14:38:05.000000000 -0700
>     +++ new/src/share/classes/java/lang/ClassNotFoundException.java  
>      2009-07-09 14:38:05.000000000 -0700
>     @@ -50,7 +50,7 @@
>      * @see     java.lang.ClassLoader#loadClass(java.lang.String, boolean)
>      * @since   JDK1.0
>      */
>     -public class ClassNotFoundException extends Exception {
>     +public class ClassNotFoundException extends
>     ReflectiveOperationException {
>        /**
>         * use serialVersionUID from JDK 1.1.X for interoperability
>         */
>     --- old/src/share/classes/java/lang/IllegalAccessException.java  
>      2009-07-09 14:38:06.000000000 -0700
>     +++ new/src/share/classes/java/lang/IllegalAccessException.java  
>      2009-07-09 14:38:06.000000000 -0700
>     @@ -56,7 +56,7 @@
>      * @see     java.lang.reflect.Constructor#newInstance(Object[])
>      * @since   JDK1.0
>      */
>     -public class IllegalAccessException extends Exception {
>     +public class IllegalAccessException extends
>     ReflectiveOperationException {
>        private static final long serialVersionUID = 6616958222490762034L;
>
>        /**
>     --- old/src/share/classes/java/lang/InstantiationException.java  
>      2009-07-09 14:38:06.000000000 -0700
>     +++ new/src/share/classes/java/lang/InstantiationException.java  
>      2009-07-09 14:38:06.000000000 -0700
>     @@ -43,7 +43,7 @@
>      * @since   JDK1.0
>      */
>     public
>     -class InstantiationException extends Exception {
>     +class InstantiationException extends ReflectiveOperationException {
>        private static final long serialVersionUID = -8441929162975509110L;
>
>        /**
>     --- old/src/share/classes/java/lang/NoSuchFieldException.java  
>      2009-07-09 14:38:07.000000000 -0700
>     +++ new/src/share/classes/java/lang/NoSuchFieldException.java  
>      2009-07-09 14:38:07.000000000 -0700
>     @@ -31,7 +31,7 @@
>      * @author  unascribed
>      * @since   JDK1.1
>      */
>     -public class NoSuchFieldException extends Exception {
>     +public class NoSuchFieldException extends
>     ReflectiveOperationException {
>        private static final long serialVersionUID = -6143714805279938260L;
>
>        /**
>     --- old/src/share/classes/java/lang/NoSuchMethodException.java  
>      2009-07-09 14:38:08.000000000 -0700
>     +++ new/src/share/classes/java/lang/NoSuchMethodException.java  
>      2009-07-09 14:38:07.000000000 -0700
>     @@ -32,7 +32,7 @@
>      * @since      JDK1.0
>      */
>     public
>     -class NoSuchMethodException extends Exception {
>     +class NoSuchMethodException extends ReflectiveOperationException {
>        private static final long serialVersionUID = 5034388446362600923L;
>
>        /**
>     ---
>     old/src/share/classes/java/lang/reflect/InvocationTargetException.java
>        2009-07-09 14:38:08.000000000 -0700
>     +++
>     new/src/share/classes/java/lang/reflect/InvocationTargetException.java
>        2009-07-09 14:38:08.000000000 -0700
>     @@ -39,7 +39,7 @@
>      * @see Method
>      * @see Constructor
>      */
>     -public class InvocationTargetException extends Exception {
>     +public class InvocationTargetException extends
>     ReflectiveOperationException {
>        /**
>         * Use serialVersionUID from JDK 1.1.X for interoperability
>         */
>     --- /dev/null    2009-07-06 20:02:10.000000000 -0700
>     +++
>     new/src/share/classes/java/lang/ReflectiveOperationException.java
>        2009-07-09 14:38:09.000000000 -0700
>     @@ -0,0 +1,88 @@
>     +/*
>     + * Copyright 2009 Sun Microsystems, Inc.  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.  Sun designates this
>     + * particular file as subject to the "Classpath" exception as
>     provided
>     + * by Sun in the LICENSE file that accompanied this code.
>     + *
>     + * 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 Sun Microsystems, Inc., 4150 Network Circle,
>     Santa Clara,
>     + * CA 95054 USA or visit www.sun.com <http://www.sun.com> if you
>     need additional information or
>     + * have any questions.
>     + */
>     +
>     +package java.lang;
>     +
>     +/**
>     + * Common superclass of exceptions thrown by reflective operations in
>     + * core reflection.
>     + *
>     + * @since 1.7
>     + */
>     +public class ReflectiveOperationException extends Exception {
>     +    static final long serialVersionUID = 123456789L;
>     +
>     +    /**
>     +     * Conqstructs a new exception with {@code null} as its detail
>     +     * message.  The cause is not initialized, and may
>     subsequently be
>     +     * initialized by a call to {@link #initCause}.
>     +     */
>     +    public ReflectiveOperationException() {
>     +        super();
>     +    }
>     +
>     +    /**
>     +     * Constructs a new exception with the specified detail message.
>     +     * The cause is not initialized, and may subsequently be
>     +     * initialized by a call to {@link #initCause}.
>     +     *
>     +     * @param   message   the detail message. The detail message
>     is saved for
>     +     *          later retrieval by the {@link #getMessage()} method.
>     +     */
>     +    public ReflectiveOperationException(String message) {
>     +        super(message);
>     +    }
>     +
>     +    /**
>     +     * Constructs a new exception with the specified detail message
>     +     * and cause.  <p>Note that the detail message associated with
>     +     * {@code cause} is <em>not</em> automatically incorporated in
>     +     * this exception's detail message.
>     +     *
>     +     * @param  message the detail message (which is saved for
>     later retrieval
>     +     *         by the {@link #getMessage()} method).
>     +     * @param  cause the cause (which is saved for later
>     retrieval by the
>     +     *         {@link #getCause()} method).  (A {@code null} value is
>     +     *         permitted, and indicates that the cause is
>     nonexistent or
>     +     *         unknown.)
>     +     */
>     +    public ReflectiveOperationException(String message, Throwable
>     cause) {
>     +        super(message, cause);
>     +    }
>     +
>     +    /**
>     +     * Constructs a new exception with the specified cause and a
>     detail
>     +     * message of {@code (cause==null ? null : cause.toString())}
>     (which
>     +     * typically contains the class and detail message of {@code
>     cause}).
>     +     *
>     +     * @param  cause the cause (which is saved for later
>     retrieval by the
>     +     *         {@link #getCause()} method).  (A {@code null} value is
>     +     *         permitted, and indicates that the cause is
>     nonexistent or
>     +     *         unknown.)
>     +     */
>     +    public ReflectiveOperationException(Throwable cause) {
>     +        super(cause);
>     +    }
>     +}
>
>
>



From xuelei.fan at sun.com  Fri Jul 10 09:40:55 2009
From: xuelei.fan at sun.com (xuelei.fan at sun.com)
Date: Fri, 10 Jul 2009 09:40:55 +0000
Subject: hg: jdk7/tl/jdk: 6852744: PIT b61: PKI test suite fails because self
	signed certificates are beingrejected
Message-ID: <20090710094126.3BCFDEE07@hg.openjdk.java.net>

Changeset: 6f26e2e5f4f3
Author:    xuelei
Date:      2009-07-10 17:27 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6f26e2e5f4f3

6852744: PIT b61: PKI test suite fails because self signed certificates are beingrejected
Summary: make the builder aware of SKID/AKID, break the internal circular dependences
Reviewed-by: mullan

! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java
+ test/java/security/cert/CertPathBuilder/selfIssued/DisableRevocation.java
+ test/java/security/cert/CertPathBuilder/selfIssued/KeyUsageMatters.java
+ test/java/security/cert/CertPathBuilder/selfIssued/README
+ test/java/security/cert/CertPathBuilder/selfIssued/StatusLoopDependency.java
+ test/java/security/cert/CertPathBuilder/selfIssued/generate.sh
+ test/java/security/cert/CertPathBuilder/selfIssued/openssl.cnf



From jason_mehrens at hotmail.com  Fri Jul 10 15:14:27 2009
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 10 Jul 2009 10:14:27 -0500
Subject: Code review request for 6857789: (reflect) Create common
	superclass of reflective exceptions
In-Reply-To: <4A568FE9.80800@univ-mlv.fr>
References: <4A56737C.50102@sun.com>
	<1ccfd1c10907091616m39b547cbqab72cec466b67900@mail.gmail.com> 
	<4A568FE9.80800@univ-mlv.fr>
Message-ID: <SNT114-W5825A895E3A5CA23FBBE0E83270@phx.gbl>


Joe,

 

Wouldn't LinkageException be a better fit than ReflectiveOperationException?  Shorter name and it would mimic the LinkageError inheritance tree introduced in JDK1.0.  I.E. LinkageError -> NoClassDefFoundError, LinkageException -> ClassNotFoundException

 

> This request seems dangerous,
> InvocationTargetException should not be retrofitted because
> usually its catch block is different from the others.


Agreed.


> John Rose recently proposes on coin-dev list a method that can be included
> in the JDK, see
> http://mail.openjdk.java.net/pipermail/coin-dev/2009-June/001954.html
> to simplify catch blocks that catch an InvocationTargetException.


I would think throwing UndeclaredThrowableException would be better than InternalError.

 

Jason

 

_________________________________________________________________
Insert movie times and more without leaving Hotmail?. 
http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd_062009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090710/7ead0dda/attachment.html>

From gnu_andrew at member.fsf.org  Fri Jul 10 15:23:02 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Fri, 10 Jul 2009 16:23:02 +0100
Subject: patch to address sun bug 6562614
In-Reply-To: <17c6771e0907091201u503fa03aibb881681e3a8cf2@mail.gmail.com>
References: <591643195.301921247151853377.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
	<17c6771e0907091201u503fa03aibb881681e3a8cf2@mail.gmail.com>
Message-ID: <17c6771e0907100823t572117eu224da41203cb1af9@mail.gmail.com>

2009/7/9 Andrew John Hughes <gnu_andrew at member.fsf.org>:
> 2009/7/9 Jon VanAlten <jon.vanalten at redhat.com>:
>> Hi,
>>
>> I've put up a webrev at http://icedtea.classpath.org/~vanaltj/webrevs/tl/patch1/index.html to address http://bugs.sun.com/view_bug.do?bug_id=6562614, also referenced on Icedtea bugzilla as http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=289 . ?Comments? ?Concerns? ?If this is an okay patch I will require someone to push for me as I do not have commit privilege.
>>
>> Thanks,
>>
>> jon
>>
>
> This is a simple cleanup patch which was discussed, and I believe
> Martin approved, here:
>
> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-July/006427.html
>
> If Jon's webrev looks ok, I'll be happy to do the actual push to the tl forest.
> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8
>

Ping! Can we commit this to tl?
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From forax at univ-mlv.fr  Fri Jul 10 15:48:25 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 10 Jul 2009 17:48:25 +0200
Subject: Code review request for 6857789: (reflect) Create
	common	superclass of reflective exceptions
In-Reply-To: <SNT114-W5825A895E3A5CA23FBBE0E83270@phx.gbl>
References: <4A56737C.50102@sun.com>	<1ccfd1c10907091616m39b547cbqab72cec466b67900@mail.gmail.com>
	<4A568FE9.80800@univ-mlv.fr>
	<SNT114-W5825A895E3A5CA23FBBE0E83270@phx.gbl>
Message-ID: <4A5762C9.4070305@univ-mlv.fr>

Jason Mehrens a ?crit :
> Joe,
>  
> Wouldn't LinkageException be a better fit than 
> ReflectiveOperationException?  Shorter name and it would mimic the 
> LinkageError inheritance tree introduced in JDK1.0.  I.E. LinkageError 
> -> NoClassDefFoundError, LinkageException -> ClassNotFoundException
>  
> > This request seems dangerous,
> > InvocationTargetException should not be retrofitted because
> > usually its catch block is different from the others.
>
> Agreed.
>
> > John Rose recently proposes on coin-dev list a method that can be 
> included
> > in the JDK, see
> > http://mail.openjdk.java.net/pipermail/coin-dev/2009-June/001954.html
> > to simplify catch blocks that catch an InvocationTargetException.
>
> I would think throwing UndeclaredThrowableException would be better 
> than InternalError.

You're right, UndeclaredThrowableException is better.

>  
> Jason
R?mi


From martinrb at google.com  Fri Jul 10 15:48:05 2009
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 10 Jul 2009 08:48:05 -0700
Subject: patch to address sun bug 6562614
In-Reply-To: <17c6771e0907100823t572117eu224da41203cb1af9@mail.gmail.com>
References: <591643195.301921247151853377.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com>
	<17c6771e0907091201u503fa03aibb881681e3a8cf2@mail.gmail.com>
	<17c6771e0907100823t572117eu224da41203cb1af9@mail.gmail.com>
Message-ID: <1ccfd1c10907100848u364c436fva8319dc633191ad8@mail.gmail.com>

On Fri, Jul 10, 2009 at 08:23, Andrew John Hughes <gnu_andrew at member.fsf.org
> wrote:

>
> Ping! Can we commit this to tl?


Getting changes into openjdk is complicated.
Different forest maintainers have different rules,
at different times.  Right now, for tl,
once you have a reviewer approval,
you can "simply" commit.

Your .hg/hgrc should look like this:

[paths]
default = http://hg.openjdk.java.net/jdk7/tl/jdk/
default-push = ssh://andrew at hg.openjdk.java.net/jdk7/tl-gate/jdk/

Your commit comment should follow the format defined
in the developer guide, including the line

Reviewed-by: martin

Martin


> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090710/6ae64593/attachment.html>

From Joe.Darcy at Sun.COM  Fri Jul 10 17:49:37 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 10 Jul 2009 10:49:37 -0700
Subject: Code review request for 6857789: (reflect) Create common
	superclass of reflective exceptions
In-Reply-To: <4A568FE9.80800@univ-mlv.fr>
References: <4A56737C.50102@sun.com>
	<1ccfd1c10907091616m39b547cbqab72cec466b67900@mail.gmail.com>
	<4A568FE9.80800@univ-mlv.fr>
Message-ID: <4A577F31.1010204@sun.com>

R?mi Forax wrote:
> This request seems dangerous,
> InvocationTargetException should not be retrofitted because
> usually its catch block is different from the others.
> As is, this patch will introduce more burden than it tries to revolve.

If needed InvocationTargetException can continue to have a separate 
catch block; if you happen to put a catch for  
ReflectiveOperationException ahead of InvocationTargetException, the 
compiler will emit an error.

-Joe



From Joe.Darcy at Sun.COM  Fri Jul 10 17:51:35 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 10 Jul 2009 10:51:35 -0700
Subject: Code review request for 6857789: (reflect) Create common
	superclass of reflective exceptions
In-Reply-To: <SNT114-W5825A895E3A5CA23FBBE0E83270@phx.gbl>
References: <4A56737C.50102@sun.com>
	<1ccfd1c10907091616m39b547cbqab72cec466b67900@mail.gmail.com>
	<4A568FE9.80800@univ-mlv.fr>
	<SNT114-W5825A895E3A5CA23FBBE0E83270@phx.gbl>
Message-ID: <4A577FA7.2050906@sun.com>

Jason Mehrens wrote:
> Joe,
>  
> Wouldn't LinkageException be a better fit than 
> ReflectiveOperationException?  Shorter name and it would mimic the 
> LinkageError inheritance tree introduced in JDK1.0.  I.E. LinkageError 
> -> NoClassDefFoundError, LinkageException -> ClassNotFoundException

"LinkageException" is a shorter name, but these conditions do not 
indicate there is a problem with linkage.  If there were a linkage 
program, you wouldn't have the reflective object to work with.

-Joe



From forax at univ-mlv.fr  Fri Jul 10 21:19:21 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Fri, 10 Jul 2009 23:19:21 +0200
Subject: Code review request for 6857789: (reflect) Create
	common	superclass of reflective exceptions
In-Reply-To: <4A577F31.1010204@sun.com>
References: <4A56737C.50102@sun.com>
	<1ccfd1c10907091616m39b547cbqab72cec466b67900@mail.gmail.com>
	<4A568FE9.80800@univ-mlv.fr> <4A577F31.1010204@sun.com>
Message-ID: <4A57B059.3020606@univ-mlv.fr>

Joseph D. Darcy a ?crit :
> R?mi Forax wrote:
>> This request seems dangerous,
>> InvocationTargetException should not be retrofitted because
>> usually its catch block is different from the others.
>> As is, this patch will introduce more burden than it tries to revolve.
>
> If needed InvocationTargetException can continue to have a separate 
> catch block; if you happen to put a catch for  
> ReflectiveOperationException ahead of InvocationTargetException, the 
> compiler will emit an error.

Yes, you can.
The problem here is that in most cases you *must* write a specific code 
to handle InvocationTargetException.

So retrofitting InvocationTargetException is in my opinion a regression 
because
it will lead to codes with more bugs
I don't see this as an improvement.

>
> -Joe
>

R?mi


From Joe.Darcy at Sun.COM  Fri Jul 10 22:13:51 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Fri, 10 Jul 2009 15:13:51 -0700
Subject: Code review request for 6857789: (reflect) Create common
	superclass of reflective exceptions
In-Reply-To: <1ccfd1c10907091616m39b547cbqab72cec466b67900@mail.gmail.com>
References: <4A56737C.50102@sun.com>
	<1ccfd1c10907091616m39b547cbqab72cec466b67900@mail.gmail.com>
Message-ID: <4A57BD1F.4090305@sun.com>

Martin Buchholz wrote:
> Thanks for this; I had a chance to use it in the past week,
> if it had been there.
>
> -----
> typo
>
> +     * Conqstructs a new exception with {@code null} as its detail

I caught this, but neglected to recreate the patch before sending the 
email.  I've spellchecked all the other comments.

>
> -----
> Start paragraphs on new lines.
>
> +     * and cause.  <p>Note that the detail message associated with
> -----

Yes, I started by copying over the constructor's text from 
java.lang.Exception, but there is no reason to not follow the current 
conventions for new code; I'll fix this before it goes back.

> Otherwise, looks good!

Thanks for the review,

-Joe

>
> Martin
>
> On Thu, Jul 9, 2009 at 15:47, Joseph D. Darcy <Joe.Darcy at sun.com 
> <mailto:Joe.Darcy at sun.com>> wrote:
>
>     Hello.
>
>     Please review the patch below to fix
>
>       6857789:  (reflect) Create common superclass of reflective
>     exceptions
>
>     Half a dozen checked exceptions thrown by methods in core
>     reflection don't have a superclass more specific than Exception,
>     requiring multiple catch blocks around code using core reflection
>     operations.    The fix is to change the direct superclass of the
>     checked exceptions in question to a new shared checked exception,
>     java.lang.ReflectiveOperationException.  This is useful whether or
>     not multi-catch is added as a language change in JDK 7.
>
>     Inserting a new level into the superclass hierarchy is a binary
>     compatible change (JLSv3 Chapter 13); the change should be
>     transparent other than to reflective operations that specifically
>     queried the superclass.   All the exception classes in question
>     already have explicit serialVersionUID fields so changing the
>     superclass will be compatible from a serialization perspective too.
>
>     (A ccc request for this change is in progress too.)
>
>     Thanks,
>
>     -Joe
>
>
>     --- old/src/share/classes/java/lang/ClassNotFoundException.java  
>      2009-07-09 14:38:05.000000000 -0700
>     +++ new/src/share/classes/java/lang/ClassNotFoundException.java  
>      2009-07-09 14:38:05.000000000 -0700
>     @@ -50,7 +50,7 @@
>      * @see     java.lang.ClassLoader#loadClass(java.lang.String, boolean)
>      * @since   JDK1.0
>      */
>     -public class ClassNotFoundException extends Exception {
>     +public class ClassNotFoundException extends
>     ReflectiveOperationException {
>        /**
>         * use serialVersionUID from JDK 1.1.X for interoperability
>         */
>     --- old/src/share/classes/java/lang/IllegalAccessException.java  
>      2009-07-09 14:38:06.000000000 -0700
>     +++ new/src/share/classes/java/lang/IllegalAccessException.java  
>      2009-07-09 14:38:06.000000000 -0700
>     @@ -56,7 +56,7 @@
>      * @see     java.lang.reflect.Constructor#newInstance(Object[])
>      * @since   JDK1.0
>      */
>     -public class IllegalAccessException extends Exception {
>     +public class IllegalAccessException extends
>     ReflectiveOperationException {
>        private static final long serialVersionUID = 6616958222490762034L;
>
>        /**
>     --- old/src/share/classes/java/lang/InstantiationException.java  
>      2009-07-09 14:38:06.000000000 -0700
>     +++ new/src/share/classes/java/lang/InstantiationException.java  
>      2009-07-09 14:38:06.000000000 -0700
>     @@ -43,7 +43,7 @@
>      * @since   JDK1.0
>      */
>     public
>     -class InstantiationException extends Exception {
>     +class InstantiationException extends ReflectiveOperationException {
>        private static final long serialVersionUID = -8441929162975509110L;
>
>        /**
>     --- old/src/share/classes/java/lang/NoSuchFieldException.java  
>      2009-07-09 14:38:07.000000000 -0700
>     +++ new/src/share/classes/java/lang/NoSuchFieldException.java  
>      2009-07-09 14:38:07.000000000 -0700
>     @@ -31,7 +31,7 @@
>      * @author  unascribed
>      * @since   JDK1.1
>      */
>     -public class NoSuchFieldException extends Exception {
>     +public class NoSuchFieldException extends
>     ReflectiveOperationException {
>        private static final long serialVersionUID = -6143714805279938260L;
>
>        /**
>     --- old/src/share/classes/java/lang/NoSuchMethodException.java  
>      2009-07-09 14:38:08.000000000 -0700
>     +++ new/src/share/classes/java/lang/NoSuchMethodException.java  
>      2009-07-09 14:38:07.000000000 -0700
>     @@ -32,7 +32,7 @@
>      * @since      JDK1.0
>      */
>     public
>     -class NoSuchMethodException extends Exception {
>     +class NoSuchMethodException extends ReflectiveOperationException {
>        private static final long serialVersionUID = 5034388446362600923L;
>
>        /**
>     ---
>     old/src/share/classes/java/lang/reflect/InvocationTargetException.java
>        2009-07-09 14:38:08.000000000 -0700
>     +++
>     new/src/share/classes/java/lang/reflect/InvocationTargetException.java
>        2009-07-09 14:38:08.000000000 -0700
>     @@ -39,7 +39,7 @@
>      * @see Method
>      * @see Constructor
>      */
>     -public class InvocationTargetException extends Exception {
>     +public class InvocationTargetException extends
>     ReflectiveOperationException {
>        /**
>         * Use serialVersionUID from JDK 1.1.X for interoperability
>         */
>     --- /dev/null    2009-07-06 20:02:10.000000000 -0700
>     +++
>     new/src/share/classes/java/lang/ReflectiveOperationException.java
>        2009-07-09 14:38:09.000000000 -0700
>     @@ -0,0 +1,88 @@
>     +/*
>     + * Copyright 2009 Sun Microsystems, Inc.  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.  Sun designates this
>     + * particular file as subject to the "Classpath" exception as
>     provided
>     + * by Sun in the LICENSE file that accompanied this code.
>     + *
>     + * 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 Sun Microsystems, Inc., 4150 Network Circle,
>     Santa Clara,
>     + * CA 95054 USA or visit www.sun.com <http://www.sun.com> if you
>     need additional information or
>     + * have any questions.
>     + */
>     +
>     +package java.lang;
>     +
>     +/**
>     + * Common superclass of exceptions thrown by reflective operations in
>     + * core reflection.
>     + *
>     + * @since 1.7
>     + */
>     +public class ReflectiveOperationException extends Exception {
>     +    static final long serialVersionUID = 123456789L;
>     +
>     +    /**
>     +     * Conqstructs a new exception with {@code null} as its detail
>     +     * message.  The cause is not initialized, and may
>     subsequently be
>     +     * initialized by a call to {@link #initCause}.
>     +     */
>     +    public ReflectiveOperationException() {
>     +        super();
>     +    }
>     +
>     +    /**
>     +     * Constructs a new exception with the specified detail message.
>     +     * The cause is not initialized, and may subsequently be
>     +     * initialized by a call to {@link #initCause}.
>     +     *
>     +     * @param   message   the detail message. The detail message
>     is saved for
>     +     *          later retrieval by the {@link #getMessage()} method.
>     +     */
>     +    public ReflectiveOperationException(String message) {
>     +        super(message);
>     +    }
>     +
>     +    /**
>     +     * Constructs a new exception with the specified detail message
>     +     * and cause.  <p>Note that the detail message associated with
>     +     * {@code cause} is <em>not</em> automatically incorporated in
>     +     * this exception's detail message.
>     +     *
>     +     * @param  message the detail message (which is saved for
>     later retrieval
>     +     *         by the {@link #getMessage()} method).
>     +     * @param  cause the cause (which is saved for later
>     retrieval by the
>     +     *         {@link #getCause()} method).  (A {@code null} value is
>     +     *         permitted, and indicates that the cause is
>     nonexistent or
>     +     *         unknown.)
>     +     */
>     +    public ReflectiveOperationException(String message, Throwable
>     cause) {
>     +        super(message, cause);
>     +    }
>     +
>     +    /**
>     +     * Constructs a new exception with the specified cause and a
>     detail
>     +     * message of {@code (cause==null ? null : cause.toString())}
>     (which
>     +     * typically contains the class and detail message of {@code
>     cause}).
>     +     *
>     +     * @param  cause the cause (which is saved for later
>     retrieval by the
>     +     *         {@link #getCause()} method).  (A {@code null} value is
>     +     *         permitted, and indicates that the cause is
>     nonexistent or
>     +     *         unknown.)
>     +     */
>     +    public ReflectiveOperationException(Throwable cause) {
>     +        super(cause);
>     +    }
>     +}
>
>
>



From martinrb at google.com  Sat Jul 11 15:23:02 2009
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 11 Jul 2009 08:23:02 -0700
Subject: Code review request for 6857789: (reflect) Create common 
	superclass of reflective exceptions
In-Reply-To: <4A577FA7.2050906@sun.com>
References: <4A56737C.50102@sun.com>
	<1ccfd1c10907091616m39b547cbqab72cec466b67900@mail.gmail.com>
	<4A568FE9.80800@univ-mlv.fr>
	<SNT114-W5825A895E3A5CA23FBBE0E83270@phx.gbl>
	<4A577FA7.2050906@sun.com>
Message-ID: <1ccfd1c10907110823o32f6dba3ta2205f701ccc66a2@mail.gmail.com>

I have some sympathy for Jason's suggestion.
The existing parallel hierarchy of classes FooError vs. FooException
makes some sense.
NoSuchMethodError is a LinkageError, so why isn't
NoSuchMethodException a LinkageException?
I consider reflectively extracting Methods and Fields
from a Class to be a form of linking, at run-time.
(But we probably don't want an IncompatibleClassChangeException
to go with IncompatibleClassChangeError)

InvocationTargetException is not a LinkageException,
but might be a ReflectiveOperationException.

Martin

On Fri, Jul 10, 2009 at 10:51, Joseph D. Darcy <Joe.Darcy at sun.com> wrote:

> Jason Mehrens wrote:
>
>> Joe,
>>  Wouldn't LinkageException be a better fit than
>> ReflectiveOperationException?  Shorter name and it would mimic the
>> LinkageError inheritance tree introduced in JDK1.0.  I.E. LinkageError ->
>> NoClassDefFoundError, LinkageException -> ClassNotFoundException
>>
>
> "LinkageException" is a shorter name, but these conditions do not indicate
> there is a problem with linkage.  If there were a linkage program, you
> wouldn't have the reflective object to work with.
>
> -Joe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090711/979ff16e/attachment.html>

From ahughes at redhat.com  Sat Jul 11 15:51:19 2009
From: ahughes at redhat.com (ahughes at redhat.com)
Date: Sat, 11 Jul 2009 15:51:19 +0000
Subject: hg: jdk7/tl/jdk: 6562614: Compiler warnings for gettimeofday in
	Inet4/Inet6AddressImpl.c
Message-ID: <20090711155158.53DD6EEA6@hg.openjdk.java.net>

Changeset: 880896883a47
Author:    andrew
Date:      2009-07-11 16:43 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/880896883a47

6562614: Compiler warnings for gettimeofday in Inet4/Inet6AddressImpl.c
Summary: Add missing header to remove compiler warnings.
Reviewed-by: martin
Contributed-by: Matthew Flaschen <matthew.flaschen at gatech.edu>

! src/solaris/native/java/net/Inet4AddressImpl.c
! src/solaris/native/java/net/Inet6AddressImpl.c



From xuelei.fan at sun.com  Mon Jul 13 15:14:33 2009
From: xuelei.fan at sun.com (xuelei.fan at sun.com)
Date: Mon, 13 Jul 2009 15:14:33 +0000
Subject: hg: jdk7/tl/jdk: 6453837: PartialCompositeContext.allEmpty is buggy
Message-ID: <20090713151510.8F407EF3F@hg.openjdk.java.net>

Changeset: d0ce095004b2
Author:    xuelei
Date:      2009-07-13 23:01 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d0ce095004b2

6453837: PartialCompositeContext.allEmpty is buggy
Reviewed-by: weijun

! src/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java



From Joe.Darcy at Sun.COM  Mon Jul 13 20:47:21 2009
From: Joe.Darcy at Sun.COM (Joe Darcy)
Date: Mon, 13 Jul 2009 13:47:21 -0700
Subject: Code review request for 6857789: (reflect) Create common
	superclass of reflective exceptions
In-Reply-To: <1ccfd1c10907110823o32f6dba3ta2205f701ccc66a2@mail.gmail.com>
References: <4A56737C.50102@sun.com>
	<1ccfd1c10907091616m39b547cbqab72cec466b67900@mail.gmail.com>
	<4A568FE9.80800@univ-mlv.fr>
	<SNT114-W5825A895E3A5CA23FBBE0E83270@phx.gbl>
	<4A577FA7.2050906@sun.com>
	<1ccfd1c10907110823o32f6dba3ta2205f701ccc66a2@mail.gmail.com>
Message-ID: <4A5B9D59.4040508@sun.com>

On 07/11/09 08:23 AM, Martin Buchholz wrote:
> I have some sympathy for Jason's suggestion.
> The existing parallel hierarchy of classes FooError vs. FooException
> makes some sense.
> NoSuchMethodError is a LinkageError, so why isn't
> NoSuchMethodException a LinkageException?

The JLS and JVMS define linkage of classes and interfaces:

* JLSv3 12.3 
http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.3
* JVMSv2 5.4 
http://java.sun.com/docs/books/jvms/second_edition/html/ConstantPool.doc.html#71418

This process completes before the reflective objects are available.

It is true that defined more broadly most of these exceptions are 
"linkage" problems, like "the method I want isn't there."  However, my 
motivation for the exception name comes from the commonality of the 
exceptions in question being generated by reflective operations, which 
are not defined to be linkage problems.  One could imagine a different 
core reflection design where there was a more direct relation between 
the error and exception conditions or where most of these erroneous 
conditions returned a marker object rather than threw an exception, but 
that is not the API we have to evolve.

-Joe

> I consider reflectively extracting Methods and Fields
> from a Class to be a form of linking, at run-time.
> (But we probably don't want an IncompatibleClassChangeException
> to go with IncompatibleClassChangeError)
>
> InvocationTargetException is not a LinkageException,
> but might be a ReflectiveOperationException.
>
> Martin
>
> On Fri, Jul 10, 2009 at 10:51, Joseph D. Darcy <Joe.Darcy at sun.com 
> <mailto:Joe.Darcy at sun.com>> wrote:
>
>     Jason Mehrens wrote:
>
>         Joe,
>          Wouldn't LinkageException be a better fit than
>         ReflectiveOperationException?  Shorter name and it would mimic
>         the LinkageError inheritance tree introduced in JDK1.0.  I.E.
>         LinkageError -> NoClassDefFoundError, LinkageException ->
>         ClassNotFoundException
>
>
>     "LinkageException" is a shorter name, but these conditions do not
>     indicate there is a problem with linkage.  If there were a linkage
>     program, you wouldn't have the reflective object to work with.
>
>     -Joe
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090713/24270056/attachment.html>

From yu-ching.peng at sun.com  Mon Jul 13 22:26:38 2009
From: yu-ching.peng at sun.com (yu-ching.peng at sun.com)
Date: Mon, 13 Jul 2009 22:26:38 +0000
Subject: hg: jdk7/tl/jdk: 6832540: IllegalArgumentException in
	ClassLoader.definePackage when classes are loaded in parallel
Message-ID: <20090713222712.EE2D7EFC6@hg.openjdk.java.net>

Changeset: beb5e5cad3ae
Author:    valeriep
Date:      2009-07-13 15:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/beb5e5cad3ae

6832540: IllegalArgumentException in ClassLoader.definePackage when classes are loaded in parallel
Summary: Modified to handle race condition for parallel-capable classloaders by re-trying/re-verifying package
Reviewed-by: alanb

! src/share/classes/java/net/URLClassLoader.java



From martinrb at google.com  Mon Jul 13 22:37:58 2009
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 13 Jul 2009 15:37:58 -0700
Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
In-Reply-To: <1247093875.31776.1324114639@webmail.messagingengine.com>
References: <NFBBKALFDCPFIDBNKAPCEEIDICAA.davidcholmes@aapt.net.au>
	<1247093875.31776.1324114639@webmail.messagingengine.com>
Message-ID: <1ccfd1c10907131537x3d566c72se2f2ead08ae06af@mail.gmail.com>

I did some stack trace eyeballing and did a mini-audit of the
LinkedBlockingDeque code, with a view to finding possible bugs,
and came up empty.  Maybe it's a deep bug in hotspot?

Ariel, it would be good if you could get a reproducible test case soonish,
while someone on the planet has the motivation and familiarity to fix it.
In another month I may disavow all knowledge of j.u.c.*Blocking*

Martin


On Wed, Jul 8, 2009 at 15:57, Ariel Weisberg <ariel at weisberg.ws> wrote:

> Hi,
>
> > The poll()ing thread is blocked waiting for the internal lock, but
> > there's
> > no indication of any thread owning that lock. You're using an OpenJDK 6
> > build ... can you try JDK7 ?
>
> I got a chance to do that today. I downloaded JDK 7 from
>
> http://www.java.net/download/jdk7/binaries/jdk-7-ea-bin-b63-linux-x64-02_jul_2009.bin
> and was able to reproduce the problem. I have attached the stack trace
> from running the 1.7 version. It is the same situation as before except
> there are 9 execution sites running on each host. There are no threads
> that are missing or that have been restarted. Foo Network thread
> (selector thread) and Network Thread - 0 are waiting on
> 0x00002aaab43d3b28. I also ran with JDK 7 and 6 and LinkedBlockingQueue
> and was not able to recreate the problem using that structure.
>
> > I don't recall anything similar to this, but I don't know what version
> > that
> > OpenJDK6 build relates to.
>
> The cluster is running on CentOS 5.3.
> >[aweisberg at 3f ~]$ rpm -qi java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5
> >Name        : java-1.6.0-openjdk           Relocations: (not relocatable)
> >Version     : 1.6.0.0                           Vendor: CentOS
> >Release     : 0.30.b09.el5                  Build Date: Tue 07 Apr 2009
> 07:24:52 PM EDT
> >Install Date: Thu 11 Jun 2009 03:27:46 PM EDT      Build Host:
> builder10.centos.org
> >Group       : Development/Languages         Source RPM:
> java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5.src.rpm
> >Size        : 76336266                         License: GPLv2 with
> exceptions
> >Signature   : DSA/SHA1, Wed 08 Apr 2009 07:55:13 AM EDT, Key ID
> a8a447dce8562897
> >URL         : http://icedtea.classpath.org/
> >Summary     : OpenJDK Runtime Environment
> >Description :
> >The OpenJDK runtime environment.
>
> > Make sure you haven't missed any exceptions occurring in other threads.
> There are no threads missing in the application (terminated threads are
> not replaced) and there is a try catch pair (prints error and rethrows)
> around the run loop of each thread. It is possible that an exception may
> have been swallowed up somewhere.
>
> >A small reproducible test case from you would be useful.
> I am working on that. I wrote a test case that mimics the application's
> use of the LBD, but I have not succeeded in reproducing the problem in
> the test case. The app has a single thread (network selector) that polls
> the LBD and several threads (ExecutionSites, and network threads that
> return results from remote ExecutionSites) that offer results into the
> queue. About 120k items will go into/out of the deque each second. In
> the actual app the problem is reproducible but inconsistent. If I run on
> my dual core laptop I can't reproduce it, and it is less likely to occur
> with a small cluster, but with 6 nodes (~560k transactions/sec) the
> problem will usually appear. Sometimes the cluster will run for several
> minutes without issue and other times it will deadlock immediately.
>
> Thanks,
>
> Ariel
>
> On Wed, 08 Jul 2009 05:14 +1000, "Martin Buchholz"
> <martinrb at google.com> wrote:
> >[+core-libs-dev]
> >
> >Doug Lea and I are (slowly) working on a new version of
> LinkedBlockingDeque.
> >I was not aware of a deadlock but can vaguely imagine how it might happen.
> >A small reproducible test case from you would be useful.
> >
> >Unfinished work in progress can be found here:
> >http://cr.openjdk.java.net/~martin/webrevs/openjdk7/BlockingQueue/<http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/BlockingQueue/>
> >
> >Martin
>
> On Wed, 08 Jul 2009 05:14 +1000, "David Holmes"
> <davidcholmes at aapt.net.au> wrote:
> >
> > Ariel,
> >
> > The poll()ing thread is blocked waiting for the internal lock, but
> > there's
> > no indication of any thread owning that lock. You're using an OpenJDK 6
> > build ... can you try JDK7 ?
> >
> > I don't recall anything similar to this, but I don't know what version
> > that
> > OpenJDK6 build relates to.
> >
> > Make sure you haven't missed any exceptions occurring in other threads.
> >
> > David Holmes
> >
> > > -----Original Message-----
> > > From: concurrency-interest-bounces at cs.oswego.edu
> > > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Ariel
> > > Weisberg
> > > Sent: Wednesday, 8 July 2009 8:31 AM
> > > To: concurrency-interest at cs.oswego.edu
> > > Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
> > >
> > >
> > > Hi all,
> > >
> > > I did a search on LinkedBlockingDeque and didn't find anything similar
> > > to what I am seeing. Attached is the stack trace from an application
> > > that is deadlocked with three threads waiting for 0x00002aaab3e91080
> > > (threads "ExecutionSite: 26", "ExecutionSite:27", and "Network
> > > Selector"). The execution sites are attempting to offer results to the
> > > deque and the network thread is trying to poll for them using the
> > > non-blocking version of poll. I am seeing the network thread never
> > > return from poll (straight poll()). Do my eyes deceive me?
> > >
> > > Thanks,
> > >
> > > Ariel Weisberg
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090713/7db96631/attachment.html>

From davidcholmes at aapt.net.au  Mon Jul 13 23:00:20 2009
From: davidcholmes at aapt.net.au (David Holmes)
Date: Tue, 14 Jul 2009 09:00:20 +1000
Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
In-Reply-To: <1ccfd1c10907131537x3d566c72se2f2ead08ae06af@mail.gmail.com>
Message-ID: <NFBBKALFDCPFIDBNKAPCAEJGICAA.davidcholmes@aapt.net.au>

Martin,

I don't think this is due to LBQ/D. This is looking similar to a couple of
other ReentrantLock/AQS "lost wakeup" hangs that I've got on the radar. We
have a reprodeucible test case for one issue but it only fails on one kind
of system - x4450. I'm on vacation most of this week but will try and get
back to this next week.

Ariel: one thing to try please see if -XX:+UseMembar fixes the problem.

Thanks,
David Holmes
  -----Original Message-----
  From: Martin Buchholz [mailto:martinrb at google.com]
  Sent: Tuesday, 14 July 2009 8:38 AM
  To: Ariel Weisberg
  Cc: davidcholmes at aapt.net.au; core-libs-dev;
concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] LinkedBlockingDeque deadlock?


  I did some stack trace eyeballing and did a mini-audit of the
  LinkedBlockingDeque code, with a view to finding possible bugs,
  and came up empty.  Maybe it's a deep bug in hotspot?

  Ariel, it would be good if you could get a reproducible test case soonish,
  while someone on the planet has the motivation and familiarity to fix it.
  In another month I may disavow all knowledge of j.u.c.*Blocking*

  Martin



  On Wed, Jul 8, 2009 at 15:57, Ariel Weisberg <ariel at weisberg.ws> wrote:

    Hi,


    > The poll()ing thread is blocked waiting for the internal lock, but
    > there's
    > no indication of any thread owning that lock. You're using an OpenJDK
6
    > build ... can you try JDK7 ?


    I got a chance to do that today. I downloaded JDK 7 from

http://www.java.net/download/jdk7/binaries/jdk-7-ea-bin-b63-linux-x64-02_jul
_2009.bin
    and was able to reproduce the problem. I have attached the stack trace
    from running the 1.7 version. It is the same situation as before except
    there are 9 execution sites running on each host. There are no threads
    that are missing or that have been restarted. Foo Network thread
    (selector thread) and Network Thread - 0 are waiting on
    0x00002aaab43d3b28. I also ran with JDK 7 and 6 and LinkedBlockingQueue
    and was not able to recreate the problem using that structure.


    > I don't recall anything similar to this, but I don't know what version
    > that
    > OpenJDK6 build relates to.


    The cluster is running on CentOS 5.3.
    >[aweisberg at 3f ~]$ rpm -qi java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5
    >Name        : java-1.6.0-openjdk           Relocations: (not
relocatable)
    >Version     : 1.6.0.0                           Vendor: CentOS
    >Release     : 0.30.b09.el5                  Build Date: Tue 07 Apr 2009
07:24:52 PM EDT
    >Install Date: Thu 11 Jun 2009 03:27:46 PM EDT      Build Host:
builder10.centos.org
    >Group       : Development/Languages         Source RPM:
java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5.src.rpm
    >Size        : 76336266                         License: GPLv2 with
exceptions
    >Signature   : DSA/SHA1, Wed 08 Apr 2009 07:55:13 AM EDT, Key ID
a8a447dce8562897
    >URL         : http://icedtea.classpath.org/
    >Summary     : OpenJDK Runtime Environment
    >Description :
    >The OpenJDK runtime environment.


    > Make sure you haven't missed any exceptions occurring in other
threads.

    There are no threads missing in the application (terminated threads are
    not replaced) and there is a try catch pair (prints error and rethrows)
    around the run loop of each thread. It is possible that an exception may
    have been swallowed up somewhere.


    >A small reproducible test case from you would be useful.

    I am working on that. I wrote a test case that mimics the application's
    use of the LBD, but I have not succeeded in reproducing the problem in
    the test case. The app has a single thread (network selector) that polls
    the LBD and several threads (ExecutionSites, and network threads that
    return results from remote ExecutionSites) that offer results into the
    queue. About 120k items will go into/out of the deque each second. In
    the actual app the problem is reproducible but inconsistent. If I run on
    my dual core laptop I can't reproduce it, and it is less likely to occur
    with a small cluster, but with 6 nodes (~560k transactions/sec) the
    problem will usually appear. Sometimes the cluster will run for several
    minutes without issue and other times it will deadlock immediately.

    Thanks,

    Ariel


    On Wed, 08 Jul 2009 05:14 +1000, "Martin Buchholz"
    <martinrb at google.com> wrote:
    >[+core-libs-dev]
    >
    >Doug Lea and I are (slowly) working on a new version of
LinkedBlockingDeque.
    >I was not aware of a deadlock but can vaguely imagine how it might
happen.
    >A small reproducible test case from you would be useful.
    >
    >Unfinished work in progress can be found here:
    >http://cr.openjdk.java.net/~martin/webrevs/openjdk7/BlockingQueue/
    >
    >Martin


    On Wed, 08 Jul 2009 05:14 +1000, "David Holmes"

    <davidcholmes at aapt.net.au> wrote:
    >

    > Ariel,
    >
    > The poll()ing thread is blocked waiting for the internal lock, but
    > there's
    > no indication of any thread owning that lock. You're using an OpenJDK
6
    > build ... can you try JDK7 ?
    >
    > I don't recall anything similar to this, but I don't know what version
    > that
    > OpenJDK6 build relates to.
    >
    > Make sure you haven't missed any exceptions occurring in other
threads.
    >
    > David Holmes
    >
    > > -----Original Message-----
    > > From: concurrency-interest-bounces at cs.oswego.edu
    > > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of
Ariel
    > > Weisberg
    > > Sent: Wednesday, 8 July 2009 8:31 AM
    > > To: concurrency-interest at cs.oswego.edu
    > > Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
    > >
    > >
    > > Hi all,
    > >
    > > I did a search on LinkedBlockingDeque and didn't find anything
similar
    > > to what I am seeing. Attached is the stack trace from an application
    > > that is deadlocked with three threads waiting for 0x00002aaab3e91080
    > > (threads "ExecutionSite: 26", "ExecutionSite:27", and "Network
    > > Selector"). The execution sites are attempting to offer results to
the
    > > deque and the network thread is trying to poll for them using the
    > > non-blocking version of poll. I am seeing the network thread never
    > > return from poll (straight poll()). Do my eyes deceive me?
    > >
    > > Thanks,
    > >
    > > Ariel Weisberg
    > >
    >


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090714/f2f74f69/attachment.html>

From ariel at weisberg.ws  Tue Jul 14 02:59:28 2009
From: ariel at weisberg.ws (Ariel Weisberg)
Date: Mon, 13 Jul 2009 22:59:28 -0400
Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
In-Reply-To: <NFBBKALFDCPFIDBNKAPCAEJGICAA.davidcholmes@aapt.net.au>
References: <NFBBKALFDCPFIDBNKAPCAEJGICAA.davidcholmes@aapt.net.au>
Message-ID: <1247540368.18990.1324916035@webmail.messagingengine.com>

Hi all.

Sorry Martin I missed reading your last email. I am not confident
that I will get a small reproducible test case in a reasonable
time frame. Reproducing it with the application is easy and I
will see what I can do about getting the source available.

One interesting thing I can tell you is that if I remove the
LinkedBlockingDeque from the mailbox of the Initiator the system
still deadlocks. The cluster has a TCP mesh topology so any node
can deliver messages to any other node. One of the connections
goes dead and neither side detects that there is a problem. I add
some assertions to the network selection thread to check that all
the connections in the cluster are still healthy and assert that
they have the correct interests set.

Here are the things it checks for  to make sure each connection
is working:
>                             for (ForeignHost.Port port :
foreignHostPorts) {
>
assert(port.m_selectionKey.isValid());
>
assert(port.m_selectionKey.selector() == m_selector);
>                             assert(port.m_channel.isOpen());
>
assert(((SocketChannel)port.m_channel).isConnected());
>
assert(((SocketChannel)port.m_channel).socket().isInputShutdown()
== false);
>
assert(((SocketChannel)port.m_channel).socket().isOutputShutdown(
) == false);
>
assert(((SocketChannel)port.m_channel).isOpen());
>
assert(((SocketChannel)port.m_channel).isRegistered());
>
assert(((SocketChannel)port.m_channel).keyFor(m_selector) !=
null);
>
assert(((SocketChannel)port.m_channel).keyFor(m_selector) ==
port.m_selectionKey);
>                             if
(m_selector.selectedKeys().contains(port.m_selectionKey)) {
>
assert((port.m_selectionKey.interestOps() & SelectionKey.OP_READ)
!= 0);
>
assert((port.m_selectionKey.interestOps() &
SelectionKey.OP_WRITE) != 0);
>                             } else {
>                                 if (port.isRunning()) {
>
assert(port.m_selectionKey.interestOps() == 0);
>                                 } else {
>
port.m_selectionKey.interestOps(SelectionKey.OP_READ |
SelectionKey.OP_WRITE);
>                                     assert((port.interestOps()
& SelectionKey.OP_READ) != 0);
>                                     assert((port.interestOps()
& SelectionKey.OP_WRITE) != 0);
>                                 }
>                             }
>                             assert(m_selector.isOpen());
>
assert(m_selector.keys().contains(port.m_selectionKey));
OP_READ | OP_WRITE is set as the interest ops every time through,
and there is no other code that changes the interest ops during
execution. The application will run for a while and then one of
the connections will stop being selected on both sides. If I step
in with the debugger on either side everything looks correct. The
keys have the correct interest ops and the selectors have the
keys in their key set.

What I suspect is happening is that a bug on one node stops the
socket from being selected (for both read and write), and
eventually the socket fills up and can't be written to by the
other side.

If I can get my VPN access together tomorrow I will run with
-XX:+UseMembar and also try running on some 8-core AMD machines.
Otherwise I will have to get to it Wednesday.

Thanks,

Ariel Weisberg


On Tue, 14 Jul 2009 05:00 +1000, "David Holmes"
<davidcholmes at aapt.net.au> wrote:

Martin,



I don't think this is due to LBQ/D. This is looking similar to a
couple of other ReentrantLock/AQS "lost wakeup" hangs that I've
got on the radar. We have a reprodeucible test case for one issue
but it only fails on one kind of system - x4450. I'm on vacation
most of this week but will try and get back to this next week.



Ariel: one thing to try please see if -XX:+UseMembar fixes the
problem.



Thanks,

David Holmes

-----Original Message-----
From: Martin Buchholz [mailto:martinrb at google.com]
Sent: Tuesday, 14 July 2009 8:38 AM
To: Ariel Weisberg
Cc: davidcholmes at aapt.net.au; core-libs-dev;
concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] LinkedBlockingDeque deadlock?

  I did some stack trace eyeballing and did a mini-audit of the
  LinkedBlockingDeque code, with a view to finding possible
  bugs,
  and came up empty.  Maybe it's a deep bug in hotspot?
  Ariel, it would be good if you could get a reproducible test
  case soonish,
  while someone on the planet has the motivation and familiarity
  to fix it.
  In another month I may disavow all knowledge of
  j.u.c.*Blocking*
  Martin

On Wed, Jul 8, 2009 at 15:57, Ariel Weisberg
<[1]ariel at weisberg.ws> wrote:

  Hi,

> The poll()ing thread is blocked waiting for the internal lock,
but
> there's
> no indication of any thread owning that lock. You're using an
OpenJDK 6
> build ... can you try JDK7 ?


  I got a chance to do that today. I downloaded JDK 7 from
  [2]http://www.java.net/download/jdk7/binaries/jdk-7-ea-bin-b63
  -linux-x64-02_jul_2009.bin
  and was able to reproduce the problem. I have attached the
  stack trace
  from running the 1.7 version. It is the same situation as
  before except
  there are 9 execution sites running on each host. There are no
  threads
  that are missing or that have been restarted. Foo Network
  thread
  (selector thread) and Network Thread - 0 are waiting on
  0x00002aaab43d3b28. I also ran with JDK 7 and 6 and
  LinkedBlockingQueue
  and was not able to recreate the problem using that structure.

> I don't recall anything similar to this, but I don't know what
version
> that
> OpenJDK6 build relates to.


  The cluster is running on CentOS 5.3.
  >[aweisberg at 3f ~]$ rpm -qi
  java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5
  >Name        : java-1.6.0-openjdk           Relocations: (not
  relocatable)
  >Version     : 1.6.0.0                           Vendor:
  CentOS
  >Release     : 0.30.b09.el5                  Build Date: Tue
  07 Apr 2009 07:24:52 PM EDT
  >Install Date: Thu 11 Jun 2009 03:27:46 PM EDT      Build
  Host: [3]builder10.centos.org
  >Group       : Development/Languages         Source RPM:
  java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5.src.rpm
  >Size        : 76336266                         License: GPLv2
  with exceptions
  >Signature   : DSA/SHA1, Wed 08 Apr 2009 07:55:13 AM EDT, Key
  ID a8a447dce8562897
  >URL         : [4]http://icedtea.classpath.org/
  >Summary     : OpenJDK Runtime Environment
  >Description :
  >The OpenJDK runtime environment.

> Make sure you haven't missed any exceptions occurring in other
threads.

  There are no threads missing in the application (terminated
  threads are
  not replaced) and there is a try catch pair (prints error and
  rethrows)
  around the run loop of each thread. It is possible that an
  exception may
  have been swallowed up somewhere.

>A small reproducible test case from you would be useful.

  I am working on that. I wrote a test case that mimics the
  application's
  use of the LBD, but I have not succeeded in reproducing the
  problem in
  the test case. The app has a single thread (network selector)
  that polls
  the LBD and several threads (ExecutionSites, and network
  threads that
  return results from remote ExecutionSites) that offer results
  into the
  queue. About 120k items will go into/out of the deque each
  second. In
  the actual app the problem is reproducible but inconsistent.
  If I run on
  my dual core laptop I can't reproduce it, and it is less
  likely to occur
  with a small cluster, but with 6 nodes (~560k
  transactions/sec) the
  problem will usually appear. Sometimes the cluster will run
  for several
  minutes without issue and other times it will deadlock
  immediately.
  Thanks,
  Ariel

On Wed, 08 Jul 2009 05:14 +1000, "Martin Buchholz"
<[5]martinrb at google.com> wrote:
>[+core-libs-dev]
>
>Doug Lea and I are (slowly) working on a new version of
LinkedBlockingDeque.
>I was not aware of a deadlock but can vaguely imagine how it
might happen.
>A small reproducible test case from you would be useful.
>
>Unfinished work in progress can be found here:
>[6]http://cr.openjdk.java.net/~martin/webrevs/openjdk7/BlockingQ
ueue/
>
>Martin


  On Wed, 08 Jul 2009 05:14 +1000, "David Holmes"

<[7]davidcholmes at aapt.net.au> wrote:
>


> Ariel,
>
> The poll()ing thread is blocked waiting for the internal lock,
but
> there's
> no indication of any thread owning that lock. You're using an
OpenJDK 6
> build ... can you try JDK7 ?
>
> I don't recall anything similar to this, but I don't know what
version
> that
> OpenJDK6 build relates to.
>
> Make sure you haven't missed any exceptions occurring in other
threads.
>
> David Holmes
>
> > -----Original Message-----
> > From: [8]concurrency-interest-bounces at cs.oswego.edu
> > [mailto:[9]concurrency-interest-bounces at cs.oswego.edu]On
Behalf Of Ariel
> > Weisberg
> > Sent: Wednesday, 8 July 2009 8:31 AM
> > To: [10]concurrency-interest at cs.oswego.edu
> > Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
> >
> >
> > Hi all,
> >
> > I did a search on LinkedBlockingDeque and didn't find
anything similar
> > to what I am seeing. Attached is the stack trace from an
application
> > that is deadlocked with three threads waiting for
0x00002aaab3e91080
> > (threads "ExecutionSite: 26", "ExecutionSite:27", and
"Network
> > Selector"). The execution sites are attempting to offer
results to the
> > deque and the network thread is trying to poll for them using
the
> > non-blocking version of poll. I am seeing the network thread
never
> > return from poll (straight poll()). Do my eyes deceive me?
> >
> > Thanks,
> >
> > Ariel Weisberg
> >
>

References

1. mailto:ariel at weisberg.ws
2. http://www.java.net/download/jdk7/binaries/jdk-7-ea-bin-b63-linux-x64-02_jul_2009.bin
3. http://builder10.centos.org/
4. http://icedtea.classpath.org/
5. mailto:martinrb at google.com
6. http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/BlockingQueue/
7. mailto:davidcholmes at aapt.net.au
8. mailto:concurrency-interest-bounces at cs.oswego.edu
9. mailto:concurrency-interest-bounces at cs.oswego.edu
  10. mailto:concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090713/409cbdb2/attachment.html>

From Xueming.Shen at Sun.COM  Tue Jul 14 19:50:39 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Tue, 14 Jul 2009 12:50:39 -0700
Subject: codereview request: 6639443/
In-Reply-To: <1ccfd1c10907131339p562edb4ejdadebc439d223f5d@mail.gmail.com>
References: <4A57CB2C.50707@sun.com>
	<1ccfd1c10907101739i782a270p50f2a3d3383f39e3@mail.gmail.com>
	<1ccfd1c10907131339p562edb4ejdadebc439d223f5d@mail.gmail.com>
Message-ID: <4A5CE18F.7030906@sun.com>

I included the core-libs-dev as you suggested.



(1)The toCodePoint change looks good.

(2)

a)    return (int)(char) uc ==uc;

    is nice:-) but I would go with the "more easy to read"

    return uc < Surrogate.UCS4_MIN;

    if it were my code. Is there a big performance gain by doing that?

b) The "buffer" version and the "array" version of generate() are not 
synced.


(3)6860431: Character.isSurrogate(char ch)

has been filed on your behalf, as well as the CCC 
http://ccc.sfbay.sun.com/6860431.
Masayoshi, would you please review the spec and add yourself as the 
reviewer? I
need the reviewer to fast-track it.

Sherman

Martin Buchholz wrote:
> Hey Character team,
>
> (should we add more people to this conversation?)
>
> One of the reasons I don't finish projects is
> that I never think the code is good enough.
> In that spirit, here are 3 reviews for you:
>
> ----
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/toCodePoint/ 
> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/toCodePoint/>
>
> Since the unoptimized code is easier to understand,
> I re-added it, in a comment.
>
> ----
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Surrogate/ 
> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/Surrogate/>
>
> I removed more (but certainly not all) uses of Surrogate
> stuff that was duplicated from Character.
>
> I added a TODO to remove more such code duplication.
>
> In generate(), there is now a genuine difference in behavior.
> I believe the intent of the original code was to handle
> negative codepoint values, but never quite got that right.
> My fix removed dead code, but was incorrect in that
> I should have preserved the intent, not just behavior.
>
> I optimized for the common case of BMP chars,
> and introduced isBMP.
>
> ----
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/isSurrogate/ 
> <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/isSurrogate/>
>
> This is a spec change.  Please file bug and CCC on my behalf.
> Synopsis: Character.isSurrogate(char ch)
> Description:
> Character.isSurrogate(char ch)
> is *the* missing method
> that we all use from Surrogate.java.
>
> Let's put it into Character.
>
> When approved, we can make sure it's tested by
> replacing calls to Surrogate.is(int) with calls to
> Character.isSurrogate(char) (but they're not exactly the same
> because the domain of the function is different.
>
> ----
>
> Thanks,
>
> Martin
>
> On Fri, Jul 10, 2009 at 17:39, Martin Buchholz <martinrb at google.com 
> <mailto:martinrb at google.com>> wrote:
>
>     Thanks for kicking me!
>
>     I have a bad habit of starting projects and not finishing them.
>     If it's OK with you, I will commit this change (and perhaps others
>     like it).  Let's call it guilt-driven software development.
>
>     Martin
>
>
>     On Fri, Jul 10, 2009 at 16:13, Xueming Shen <Xueming.Shen at sun.com
>     <mailto:Xueming.Shen at sun.com>> wrote:
>
>         I'm cleaning up the 7 bug list, this one is the one you did
>         not finish/putback before left.
>
>         http://cr.openjdk.java.net/~sherman/6639443/webrev
>         <http://cr.openjdk.java.net/%7Esherman/6639443/webrev>
>
>         The fix looks fine. Can you "review" it as well?
>
>         Masayoshi, please take a look as well.
>
>         Btw, where is the regression tests for supplementary
>         characters? I can't find it under test/java/lang...
>
>         Thanks!
>         Sherman
>
>
>



From martinrb at google.com  Tue Jul 14 20:15:15 2009
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 14 Jul 2009 13:15:15 -0700
Subject: codereview request: 6639443/
In-Reply-To: <4A5CE18F.7030906@sun.com>
References: <4A57CB2C.50707@sun.com>
	<1ccfd1c10907101739i782a270p50f2a3d3383f39e3@mail.gmail.com>
	<1ccfd1c10907131339p562edb4ejdadebc439d223f5d@mail.gmail.com>
	<4A5CE18F.7030906@sun.com>
Message-ID: <1ccfd1c10907141315t32d3d6c1wc87a630f0642310@mail.gmail.com>

On Tue, Jul 14, 2009 at 12:50, Xueming Shen <Xueming.Shen at sun.com> wrote:

>
> (2)
>
> a)    return (int)(char) uc ==uc;
>
>   is nice:-) but I would go with the "more easy to read"
>
>   return uc < Surrogate.UCS4_MIN;
>
>   if it were my code. Is there a big performance gain by doing that?
>

That's almost, but not exactly the same - uc might be negative.
(I don't know whether that can ever happen, though)

My code is likely to be slightly faster than

return uc < Surrogate.UCS4_MIN && uc >= 0;


> b) The "buffer" version and the "array" version of generate() are not
> synced.
>

Yikes!  Good catch.  Fixed - webrev regenerated.

Thanks,

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090714/2cd59bd0/attachment.html>

From Ulf.Zibis at gmx.de  Tue Jul 14 21:01:18 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 14 Jul 2009 23:01:18 +0200
Subject: codereview request: 6639443/
In-Reply-To: <4A5CE18F.7030906@sun.com>
References: <4A57CB2C.50707@sun.com>	<1ccfd1c10907101739i782a270p50f2a3d3383f39e3@mail.gmail.com>	<1ccfd1c10907131339p562edb4ejdadebc439d223f5d@mail.gmail.com>
	<4A5CE18F.7030906@sun.com>
Message-ID: <4A5CF21E.20505@gmx.de>

Am 14.07.2009 21:50, Xueming Shen schrieb:
> I included the core-libs-dev as you suggested.
>
> (3)6860431: Character.isSurrogate(char ch)
>
> has been filed on your behalf, as well as the CCC 
> http://ccc.sfbay.sun.com/6860431.
> Masayoshi, would you please review the spec and add yourself as the 
> reviewer? I
> need the reviewer to fast-track it.

Hehe, I was first:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6798511

;-)

-Ulf




From martinrb at google.com  Tue Jul 14 21:36:34 2009
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 14 Jul 2009 14:36:34 -0700
Subject: codereview request: 6639443/
In-Reply-To: <4A5CF21E.20505@gmx.de>
References: <4A57CB2C.50707@sun.com>
	<1ccfd1c10907101739i782a270p50f2a3d3383f39e3@mail.gmail.com>
	<1ccfd1c10907131339p562edb4ejdadebc439d223f5d@mail.gmail.com>
	<4A5CE18F.7030906@sun.com> <4A5CF21E.20505@gmx.de>
Message-ID: <1ccfd1c10907141436w176ed97byb1146dd06fd2f99@mail.gmail.com>

Sorry, Ulf.

The bug duplication might have been avoided
if the bug database was more searchable.
I need a command named .... jbugs ...

Martin

On Tue, Jul 14, 2009 at 14:01, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

> Am 14.07.2009 21:50, Xueming Shen schrieb:
>
>> I included the core-libs-dev as you suggested.
>>
>> (3)6860431: Character.isSurrogate(char ch)
>>
>> has been filed on your behalf, as well as the CCC
>> http://ccc.sfbay.sun.com/6860431.
>> Masayoshi, would you please review the spec and add yourself as the
>> reviewer? I
>> need the reviewer to fast-track it.
>>
>
> Hehe, I was first:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6798511
>
> ;-)
>
> -Ulf
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090714/dfa3a541/attachment.html>

From Ulf.Zibis at gmx.de  Tue Jul 14 21:53:17 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Tue, 14 Jul 2009 23:53:17 +0200
Subject: codereview request: 6639443/
In-Reply-To: <1ccfd1c10907141436w176ed97byb1146dd06fd2f99@mail.gmail.com>
References: <4A57CB2C.50707@sun.com>	
	<1ccfd1c10907101739i782a270p50f2a3d3383f39e3@mail.gmail.com>	
	<1ccfd1c10907131339p562edb4ejdadebc439d223f5d@mail.gmail.com>	
	<4A5CE18F.7030906@sun.com> <4A5CF21E.20505@gmx.de>
	<1ccfd1c10907141436w176ed97byb1146dd06fd2f99@mail.gmail.com>
Message-ID: <4A5CFE4D.7020000@gmx.de>

Martin, no problem!

See: 
http://mail.openjdk.java.net/pipermail/web-discuss/2009-March/000066.html

-Ulf


Am 14.07.2009 23:36, Martin Buchholz schrieb:
> Sorry, Ulf.
>
> The bug duplication might have been avoided
> if the bug database was more searchable.
> I need a command named .... jbugs ...
>
> Martin
>
> On Tue, Jul 14, 2009 at 14:01, Ulf Zibis <Ulf.Zibis at gmx.de 
> <mailto:Ulf.Zibis at gmx.de>> wrote:
>
>     Am 14.07.2009 21:50, Xueming Shen schrieb:
>
>         I included the core-libs-dev as you suggested.
>
>         (3)6860431: Character.isSurrogate(char ch)
>
>         has been filed on your behalf, as well as the CCC
>         http://ccc.sfbay.sun.com/6860431.
>         Masayoshi, would you please review the spec and add yourself
>         as the reviewer? I
>         need the reviewer to fast-track it.
>
>
>     Hehe, I was first:
>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6798511
>
>     ;-)
>
>     -Ulf
>
>
>



From pugalfromplanetearth at gmail.com  Wed Jul 15 08:23:47 2009
From: pugalfromplanetearth at gmail.com (Ganesan Pugalendhi)
Date: Wed, 15 Jul 2009 13:53:47 +0530
Subject: Reg : How to contribute
Message-ID: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>

Hi

 I have more then 6+ years of working experience in java (Java ME (3 Years)
and Java SE and EE (3 + yrs)), I have implemented RTP/RTCP stack in j2me,
designed and implemented Canvas based UI frame work for J2ME clients and
Architected many  Java EE projects.  I like to contribute to JDK7 but i
don't know how. Can any one help me.

Thanks and Regards
- Pugal.G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090715/2cf4dec3/attachment.html>

From Ulf.Zibis at gmx.de  Wed Jul 15 08:34:47 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 15 Jul 2009 10:34:47 +0200
Subject: Reg : How to contribute
In-Reply-To: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
Message-ID: <4A5D94A7.8060104@gmx.de>

See:
https://jdk-collaboration.dev.java.net/
http://openjdk.java.net/
http://openjdk.java.net/contribute/

-Ulf


Am 15.07.2009 10:23, Ganesan Pugalendhi schrieb:
> Hi
>
>  I have more then 6+ years of working experience in java (Java ME (3 
> Years) and Java SE and EE (3 + yrs)), I have implemented RTP/RTCP 
> stack in j2me, designed and implemented Canvas based UI frame work for 
> J2ME clients and Architected many  Java EE projects.  I like to 
> contribute to JDK7 but i don't know how. Can any one help me.
>
> Thanks and Regards
> - Pugal.G



From maurizio.cimadamore at sun.com  Wed Jul 15 09:30:46 2009
From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com)
Date: Wed, 15 Jul 2009 09:30:46 +0000
Subject: hg: jdk7/tl/langtools: 6846972: cannot access member of raw type when
	erasure change overriding into overloading
Message-ID: <20090715093051.57B11E103@hg.openjdk.java.net>

Changeset: ad07b7ea9685
Author:    mcimadamore
Date:      2009-07-15 10:25 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ad07b7ea9685

6846972: cannot access member of raw type when erasure change overriding into overloading
Summary: fix of 6400189 caused a nasty problem in method resolution
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/tools/javac/generics/rawOverride/T6846972.java



From Dalibor.Topic at Sun.COM  Wed Jul 15 11:01:56 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Wed, 15 Jul 2009 13:01:56 +0200
Subject: Reg : How to contribute
In-Reply-To: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
Message-ID: <4A5DB724.50702@sun.com>

Ganesan Pugalendhi wrote:
> Hi
> 
>  I have more then 6+ years of working experience in java (Java ME (3
> Years) and Java SE and EE (3 + yrs)), I have implemented RTP/RTCP stack
> in j2me, designed and implemented Canvas based UI frame work for J2ME
> clients and Architected many  Java EE projects.  I like to contribute to
> JDK7 but i don't know how. Can any one help me.

A good start is the OpenJDK developer guide - see 
http://openjdk.java.net/guide/ to learn how the project works. A good way
to understand how to start contributing patches is 
http://openjdk.java.net/contribute/

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin H?ring




From gustav.trede at gmail.com  Wed Jul 15 11:52:25 2009
From: gustav.trede at gmail.com (gustav trede)
Date: Wed, 15 Jul 2009 13:52:25 +0200
Subject: Math trig intrinsics and compiler options
Message-ID: <311e0eaf0907150452y9c0e39cibfe57664b262fb3f@mail.gmail.com>

Hello,

Azeem Jiva told me an easy way to improve trig performance.
Changing the intrinsics to use an existing but faster path gives me a boost
of roughly 40% for the Math cos and sin on solaris x64.


library_call.cpp

bool LibraryCallKit::inline_math_native(vmIntrinsics::ID id) {
  switch (id) {

   case vmIntrinsics::_dcos: return Matcher::has_match_rule(Op_CosD) ?
runtime_math(OptoRuntime::Math_D_D_Type(), CAST_FROM_FN_PTR(address,
SharedRuntime::dcos), "COS") : false;
   case vmIntrinsics::_dsin: return Matcher::has_match_rule(Op_SinD) ?
runtime_math(OptoRuntime::Math_D_D_Type(), CAST_FROM_FN_PTR(address,
SharedRuntime::dsin), "SIN") : false;
   case vmIntrinsics::_dtan: return Matcher::has_match_rule(Op_TanD) ?
runtime_math(OptoRuntime::Math_D_D_Type(), CAST_FROM_FN_PTR(address,
SharedRuntime::dtan), "TAN") : false;
   case vmIntrinsics::_dlog:   return Matcher::has_match_rule(Op_LogD) ?
runtime_math(OptoRuntime::Math_D_D_Type(), CAST_FROM_FN_PTR(address,
SharedRuntime::dlog), "LOG") : false;
   case vmIntrinsics::_dlog10: return Matcher::has_match_rule(Op_Log10D) ?
runtime_math(OptoRuntime::Math_D_D_Type(), CAST_FROM_FN_PTR(address,
SharedRuntime::dlog10), "LOG10") : false;


Is there any potential problem with such a patch  ?





Compiler flags is another area of interest.
Both linux and windows platforms seems to turn off optimizations for
sharedRuntimeTrig.cpp :
sharedRuntimeTrig.cpp   has
#ifdef WIN32
# pragma optimize ( "", off )
#endif


hotspot/make/linux/makefiles/i486.make:# The copied fdlibm routines in
sharedRuntimeTrig.o must not be optimized
hotspot/make/linux/makefiles/i486.make:OPT_CFLAGS/sharedRuntimeTrig.o =
$(OPT_CFLAGS/NOOPT)
hotspot/make/linux/makefiles/amd64.make:# The copied fdlibm routines in
sharedRuntimeTrig.o must not be optimized
hotspot/make/linux/makefiles/amd64.make:OPT_CFLAGS/sharedRuntimeTrig.o =
$(OPT_CFLAGS/NOOPT)

Do we know if the situation has changed for these platforms ?


-- 
regards
 gustav trede
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090715/98e80f89/attachment.html>

From Christian.Thalinger at Sun.COM  Wed Jul 15 12:26:52 2009
From: Christian.Thalinger at Sun.COM (Christian Thalinger)
Date: Wed, 15 Jul 2009 14:26:52 +0200
Subject: Math trig intrinsics and compiler options
In-Reply-To: <311e0eaf0907150452y9c0e39cibfe57664b262fb3f@mail.gmail.com>
References: <311e0eaf0907150452y9c0e39cibfe57664b262fb3f@mail.gmail.com>
Message-ID: <4A5DCB0C.1070506@Sun.COM>

gustav trede wrote:
> Hello,

You should better ask these questions on hotspot-dev.

-- Christian


From neal at gafter.com  Wed Jul 15 14:26:53 2009
From: neal at gafter.com (Neal Gafter)
Date: Wed, 15 Jul 2009 07:26:53 -0700
Subject: Reg : How to contribute
In-Reply-To: <4A5DB724.50702@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com> 
	<4A5DB724.50702@sun.com>
Message-ID: <15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>

On Wed, Jul 15, 2009 at 4:01 AM, Dalibor Topic <Dalibor.Topic at sun.com>wrote:

>  A good start is the OpenJDK developer guide - see
> http://openjdk.java.net/guide/ to learn how the project works.


That set of pages is mostly filled with promises of the form "This section
will contain...".  For
example<http://openjdk.java.net/guide/processWorkflow.html>
:
Process Workflow version 0.01

This is the main navigation for the document and the primary entry point. It
is intended to be a quick start and overview which will have a hyperlinked
diagram indicating sample work flows for common operations such as
submitting a bug fix and adding a new API.

At one time these sections also contained a schedule for when they would be
completed, but those dates have long since passed and the schedule has been
removed.  It appears that supporting external contributors was never very
high-priority.

-Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090715/de99417c/attachment.html>

From Ulf.Zibis at gmx.de  Wed Jul 15 14:39:31 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 15 Jul 2009 16:39:31 +0200
Subject: Reg : How to contribute
In-Reply-To: <15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
Message-ID: <4A5DEA23.2090100@gmx.de>

Am 15.07.2009 16:26, Neal Gafter schrieb:
> On Wed, Jul 15, 2009 at 4:01 AM, Dalibor Topic <Dalibor.Topic at sun.com 
> <mailto:Dalibor.Topic at sun.com>> wrote:
>
>     A good start is the OpenJDK developer guide - see
>     http://openjdk.java.net/guide/ to learn how the project works.
>
>
> That set of pages is mostly filled with promises of the form "This 
> section will contain...".  For example 
> <http://openjdk.java.net/guide/processWorkflow.html>:
>
>
>   Process Workflow
>
> version 0.01
>
> This is the main navigation for the document and the primary entry 
> point. It is intended to be a quick start and overview which will have 
> a hyperlinked diagram indicating sample work flows for common 
> operations such as submitting a bug fix and adding a new API.
>
> At one time these sections also contained a schedule for when they 
> would be completed, but those dates have long since passed and the 
> schedule has been removed.  It appears that supporting external 
> contributors was never very high-priority.
>
> -Neal
>

I think, it would be good idea to make the webrev tool available for 
external contributors too. It's the perfect tool for discussion on 
changesets.
Additionally IMHO support for working with NetBeans is not as it could be.

-Ulf




From Dalibor.Topic at Sun.COM  Wed Jul 15 14:41:30 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Wed, 15 Jul 2009 16:41:30 +0200
Subject: Reg : How to contribute
In-Reply-To: <15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
Message-ID: <4A5DEA9A.2060208@sun.com>

Neal,

Are you interested in improving the developer guide?

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin H?ring




From gnu_andrew at member.fsf.org  Wed Jul 15 14:41:42 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 15 Jul 2009 15:41:42 +0100
Subject: Fwd: Reg : How to contribute
In-Reply-To: <17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de>
	<17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com>
Message-ID: <17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>

2009/7/15 Ulf Zibis <Ulf.Zibis at gmx.de>:
> Am 15.07.2009 16:26, Neal Gafter schrieb:
>>
>> On Wed, Jul 15, 2009 at 4:01 AM, Dalibor Topic <Dalibor.Topic at sun.com
>> <mailto:Dalibor.Topic at sun.com>> wrote:
>>
>> ? ?A good start is the OpenJDK developer guide - see
>> ? ?http://openjdk.java.net/guide/ to learn how the project works.
>>
>>
>> That set of pages is mostly filled with promises of the form "This section
>> will contain...". ?For example
>> <http://openjdk.java.net/guide/processWorkflow.html>:
>>
>>
>> ?Process Workflow
>>
>> version 0.01
>>
>> This is the main navigation for the document and the primary entry point.
>> It is intended to be a quick start and overview which will have a
>> hyperlinked diagram indicating sample work flows for common operations such
>> as submitting a bug fix and adding a new API.
>>
>> At one time these sections also contained a schedule for when they would
>> be completed, but those dates have long since passed and the schedule has
>> been removed. ?It appears that supporting external contributors was never
>> very high-priority.
>>
>> -Neal
>>
>
> I think, it would be good idea to make the webrev tool available for
> external contributors too. It's the perfect tool for discussion on
> changesets.
> Additionally IMHO support for working with NetBeans is not as it could be.
>
> -Ulf
>
>
>

Err... webrev is available, several external contributors such as
myself have already posted patches using it.

http://blogs.sun.com/jcc/entry/webrev_script_updated
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8


From Dalibor.Topic at Sun.COM  Wed Jul 15 14:45:15 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Wed, 15 Jul 2009 16:45:15 +0200
Subject: Reg : How to contribute
In-Reply-To: <4A5DEA23.2090100@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de>
Message-ID: <4A5DEB7B.6090500@sun.com>

Ulf Zibis wrote: 
> I think, it would be good idea to make the webrev tool available for
> external contributors too. It's the perfect tool for discussion on
> changesets.

Hi Ulf,

The webrev tool is available at http://blogs.sun.com/jcc/resource/webrev

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin H?ring




From Lance.Andersen at Sun.COM  Wed Jul 15 14:48:05 2009
From: Lance.Andersen at Sun.COM (Lance J. Andersen)
Date: Wed, 15 Jul 2009 10:48:05 -0400
Subject: Fwd: Reg : How to contribute
In-Reply-To: <17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de>
	<17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com>
	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
Message-ID: <4A5DEC25.3000607@sun.com>

I do agree with Ulf

I think it would be useful to have webrev available from the openjdk 
project  home page or a least a pointer to where to obtain a copy.

While you are correct you can find copies via google search,  having the 
tools that are useful accessible from the openjdk site would be a plus



Andrew John Hughes wrote:
> 2009/7/15 Ulf Zibis <Ulf.Zibis at gmx.de>:
>   
>> Am 15.07.2009 16:26, Neal Gafter schrieb:
>>     
>>> On Wed, Jul 15, 2009 at 4:01 AM, Dalibor Topic <Dalibor.Topic at sun.com
>>> <mailto:Dalibor.Topic at sun.com>> wrote:
>>>
>>>    A good start is the OpenJDK developer guide - see
>>>    http://openjdk.java.net/guide/ to learn how the project works.
>>>
>>>
>>> That set of pages is mostly filled with promises of the form "This section
>>> will contain...".  For example
>>> <http://openjdk.java.net/guide/processWorkflow.html>:
>>>
>>>
>>>  Process Workflow
>>>
>>> version 0.01
>>>
>>> This is the main navigation for the document and the primary entry point.
>>> It is intended to be a quick start and overview which will have a
>>> hyperlinked diagram indicating sample work flows for common operations such
>>> as submitting a bug fix and adding a new API.
>>>
>>> At one time these sections also contained a schedule for when they would
>>> be completed, but those dates have long since passed and the schedule has
>>> been removed.  It appears that supporting external contributors was never
>>> very high-priority.
>>>
>>> -Neal
>>>
>>>       
>> I think, it would be good idea to make the webrev tool available for
>> external contributors too. It's the perfect tool for discussion on
>> changesets.
>> Additionally IMHO support for working with NetBeans is not as it could be.
>>
>> -Ulf
>>
>>
>>
>>     
>
> Err... webrev is available, several external contributors such as
> myself have already posted patches using it.
>
> http://blogs.sun.com/jcc/entry/webrev_script_updated
> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090715/75e7a08e/attachment.html>

From Ulf.Zibis at gmx.de  Wed Jul 15 14:49:13 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 15 Jul 2009 16:49:13 +0200
Subject: Fwd: Reg : How to contribute
In-Reply-To: <17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>	<4A5DB724.50702@sun.com>	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>	<4A5DEA23.2090100@gmx.de>	<17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com>
	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
Message-ID: <4A5DEC69.5080402@gmx.de>

Andrew,

thanks for the info. :-)

Can you give a hint how to register on webrev server, and how to make it 
work?

-Ulf


Am 15.07.2009 16:41, Andrew John Hughes schrieb:
> 2009/7/15 Ulf Zibis <Ulf.Zibis at gmx.de>:
>   
>>
>> I think, it would be good idea to make the webrev tool available for
>> external contributors too. It's the perfect tool for discussion on
>> changesets.
>> Additionally IMHO support for working with NetBeans is not as it could be.
>>
>> -Ulf
>>
>>
>>
>>     
>
> Err... webrev is available, several external contributors such as
> myself have already posted patches using it.
>
> http://blogs.sun.com/jcc/entry/webrev_script_updated
> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>
>
>   



From Ulf.Zibis at gmx.de  Wed Jul 15 14:52:06 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 15 Jul 2009 16:52:06 +0200
Subject: Reg : How to contribute
In-Reply-To: <4A5DEB7B.6090500@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
Message-ID: <4A5DED16.2080407@gmx.de>

Am 15.07.2009 16:45, Dalibor Topic schrieb:
> Ulf Zibis wrote: 
>   
>> I think, it would be good idea to make the webrev tool available for
>> external contributors too. It's the perfect tool for discussion on
>> changesets.
>>     
>
> Hi Ulf,
>
> The webrev tool is available at http://blogs.sun.com/jcc/resource/webrev
>
> cheers,
> dalibor topic
>   

Thanks Dalibor,

but what to do with this script to make it work for me?

-Ulf





From Dalibor.Topic at Sun.COM  Wed Jul 15 14:55:24 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Wed, 15 Jul 2009 16:55:24 +0200
Subject: Reg : How to contribute
In-Reply-To: <4A5DED16.2080407@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
	<4A5DED16.2080407@gmx.de>
Message-ID: <4A5DEDDC.8070106@sun.com>

Ulf Zibis wrote:
> but what to do with this script to make it work for me?

I'm not sure I understand the question correctly - webrev is a shell script
that uses ksh, so you could mark it as executable and run it using ksh, for
example.

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin H?ring




From neal at gafter.com  Wed Jul 15 15:02:15 2009
From: neal at gafter.com (Neal Gafter)
Date: Wed, 15 Jul 2009 08:02:15 -0700
Subject: Reg : How to contribute
In-Reply-To: <4A5DEA9A.2060208@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com> 
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com> 
	<4A5DEA9A.2060208@sun.com>
Message-ID: <15e8b9d20907150802t3dfd4f3cr267e79ccc0979281@mail.gmail.com>

2009/7/15 Dalibor Topic <Dalibor.Topic at sun.com>

> Neal,
>
> Are you interested in improving the developer guide?
>

Unfortunately, I have no special access to what Sun is putting in place, so
I'm not the right person to be documenting things.  I still haven't figured
out, for example, what process external contributors are supposed to go
through for API changes.  (Yes, I know the JCP defines the specs and the
openjdk just implements them, but there is no platform JSR for SE 7 and yet
API changes are being put into openjdk).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090715/cdfaa6fe/attachment.html>

From gnu_andrew at member.fsf.org  Wed Jul 15 15:32:20 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 15 Jul 2009 16:32:20 +0100
Subject: Reg : How to contribute
In-Reply-To: <15e8b9d20907150802t3dfd4f3cr267e79ccc0979281@mail.gmail.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA9A.2060208@sun.com>
	<15e8b9d20907150802t3dfd4f3cr267e79ccc0979281@mail.gmail.com>
Message-ID: <17c6771e0907150832t3c2ee88bndf9d7f7add125b22@mail.gmail.com>

2009/7/15 Neal Gafter <neal at gafter.com>:
> 2009/7/15 Dalibor Topic <Dalibor.Topic at sun.com>
>>
>> Neal,
>>
>> Are you interested in improving the developer guide?
>
> Unfortunately, I have no special access to what Sun is putting in place, so
> I'm not the right person to be documenting things.? I still haven't figured
> out, for example, what process external contributors are supposed to go
> through for API changes.? (Yes, I know the JCP defines the specs and the
> openjdk just implements them, but there is no platform JSR for SE 7 and yet
> API changes are being put into openjdk).
>
>

There doesn't seem to be an external process yet.  At least, that's
what I gathered from this discussion:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-July/002007.html
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Ulf.Zibis at gmx.de  Wed Jul 15 16:32:47 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 15 Jul 2009 18:32:47 +0200
Subject: Reg : How to contribute
In-Reply-To: <4A5DEDDC.8070106@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
	<4A5DED16.2080407@gmx.de> <4A5DEDDC.8070106@sun.com>
Message-ID: <4A5E04AF.2010302@gmx.de>

Am 15.07.2009 16:55, Dalibor Topic schrieb:
> Ulf Zibis wrote:
>   
>> but what to do with this script to make it work for me?
>>     
>
> I'm not sure I understand the question correctly - webrev is a shell script
> that uses ksh, so you could mark it as executable and run it using ksh, for
> example.
>
>   

Dalibor, thanks.

I'm not sure, if this runs on Windows. I have looked in my CYGWIN shell,
but ksh is not available. May be I can upgrade it.

But does this script help me, to have an account on webrev server ?

... and what does this script do? Does it open a GUI where I can enter
the mercurial changeset to upload?

-Ulf





From gnu_andrew at member.fsf.org  Wed Jul 15 17:35:09 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 15 Jul 2009 18:35:09 +0100
Subject: Reg : How to contribute
In-Reply-To: <4A5E04AF.2010302@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
	<4A5DED16.2080407@gmx.de> <4A5DEDDC.8070106@sun.com>
	<4A5E04AF.2010302@gmx.de>
Message-ID: <17c6771e0907151035m79ca99cah49977ce7a74378bd@mail.gmail.com>

2009/7/15 Ulf Zibis <Ulf.Zibis at gmx.de>:
> Am 15.07.2009 16:55, Dalibor Topic schrieb:
>>
>> Ulf Zibis wrote:
>>
>>>
>>> but what to do with this script to make it work for me?
>>>
>>
>> I'm not sure I understand the question correctly - webrev is a shell
>> script
>> that uses ksh, so you could mark it as executable and run it using ksh,
>> for
>> example.
>>
>>
>
> Dalibor, thanks.
>
> I'm not sure, if this runs on Windows. I have looked in my CYGWIN shell,
> but ksh is not available. May be I can upgrade it.
>
> But does this script help me, to have an account on webrev server ?
>
> ... and what does this script do? Does it open a GUI where I can enter
> the mercurial changeset to upload?
>
> -Ulf
>
>
>
>

No, it generates a series of HTML and diff files for you to upload to
a web server for review on the lists.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Lance.Andersen at Sun.COM  Wed Jul 15 17:36:49 2009
From: Lance.Andersen at Sun.COM (Lance J. Andersen)
Date: Wed, 15 Jul 2009 13:36:49 -0400
Subject: Reg : How to contribute
In-Reply-To: <4A5E04AF.2010302@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
	<4A5DED16.2080407@gmx.de>
	<4A5DEDDC.8070106@sun.com> <4A5E04AF.2010302@gmx.de>
Message-ID: <4A5E13B1.6080406@sun.com>



Ulf Zibis wrote:
> Am 15.07.2009 16:55, Dalibor Topic schrieb:
>> Ulf Zibis wrote:
>>  
>>> but what to do with this script to make it work for me?
>>>     
>>
>> I'm not sure I understand the question correctly - webrev is a shell 
>> script
>> that uses ksh, so you could mark it as executable and run it using 
>> ksh, for
>> example.
>>
>>   
>

Ulf
> Dalibor, thanks.
>
> I'm not sure, if this runs on Windows. I have looked in my CYGWIN shell,
> but ksh is not available. May be I can upgrade it.
>
> But does this script help me, to have an account on webrev server ?
There is no webrev server, 
>
> ... and what does this script do? Does it open a GUI where I can enter
> the mercurial changeset to upload?
The script will create a set of diffs which you can view easily in a web 
browser.  Much easier to read than a standard diff. 
>
> -Ulf
>
>
>


From Frances.Ho at Sun.COM  Wed Jul 15 17:19:39 2009
From: Frances.Ho at Sun.COM (Frances Ho)
Date: Wed, 15 Jul 2009 10:19:39 -0700
Subject: Reg : How to contribute
In-Reply-To: <4A5DEDDC.8070106@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
	<4A5DED16.2080407@gmx.de> <4A5DEDDC.8070106@sun.com>
Message-ID: <4A5E0FAB.8060607@sun.com>


Jessie (Jean-Christophe) has been working on a Java version of
webrev.  Jessie - can you share a bit of what it'll cover?


-Frances


On 07/15/09 07:55, Dalibor Topic wrote:
> Ulf Zibis wrote:
>> but what to do with this script to make it work for me?
> 
> I'm not sure I understand the question correctly - webrev is a shell script
> that uses ksh, so you could mark it as executable and run it using ksh, for
> example.
> 
> cheers,
> dalibor topic


From Ulf.Zibis at gmx.de  Wed Jul 15 18:01:40 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Wed, 15 Jul 2009 20:01:40 +0200
Subject: Reg : How to contribute
In-Reply-To: <4A5E13B1.6080406@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
	<4A5DED16.2080407@gmx.de> <4A5DEDDC.8070106@sun.com>
	<4A5E04AF.2010302@gmx.de> <4A5E13B1.6080406@sun.com>
Message-ID: <4A5E1984.3070004@gmx.de>

Am 15.07.2009 19:36, Lance J. Andersen schrieb:
>
>
> Ulf Zibis wrote:
>
>> But does this script help me, to have an account on webrev server ?
> There is no webrev server,

I just referred to http://cr.openjdk.java.net/ :


    General

_This server_ provides storage and display of code review materials such 
as webrevs and other artifacts related to the OpenJDK 
<http://openjdk.java.net/> Community. If you are interested in 
monitoring recent reviews, try our review feed here 
<http://cr.openjdk.java.net/feed.atom>.

Any user with push access to the OpenJDK Mercurial 
<http://hg.openjdk.java.net> server can publish materials on _this 
server_. Users can upload files to temporary storage using secure 
methods (rsync, scp, and sftp).



>>
>> ... and what does this script do? Does it open a GUI where I can enter
>> the mercurial changeset to upload?
> The script will create a set of diffs which you can view easily in a 
> web browser.  Much easier to read than a standard diff.

OK, thanks. Is there any tutorial for best practice of this script. 
Should it be started in same folder as local .hg repository?
But anyway, I still need an account on your whatever server to publish 
those set of diffs.

-Ulf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090715/b4aecc51/attachment.html>

From maurizio.cimadamore at sun.com  Wed Jul 15 16:06:28 2009
From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com)
Date: Wed, 15 Jul 2009 16:06:28 +0000
Subject: hg: jdk7/tl/langtools: 6860795: NullPointerException when compiling a
	negative java source
Message-ID: <20090715160633.68621E13A@hg.openjdk.java.net>

Changeset: 90d40dd5cfc7
Author:    mcimadamore
Date:      2009-07-15 17:01 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/90d40dd5cfc7

6860795: NullPointerException when compiling a negative java source
Summary: Rich formatter shouldn't propagate visits on method symbols that have a null type
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
+ test/tools/javac/Diagnostics/6860795/T6860795.java
+ test/tools/javac/Diagnostics/6860795/T6860795.out



From Lance.Andersen at Sun.COM  Wed Jul 15 18:33:52 2009
From: Lance.Andersen at Sun.COM (Lance J. Andersen)
Date: Wed, 15 Jul 2009 14:33:52 -0400
Subject: Reg : How to contribute
In-Reply-To: <4A5E1984.3070004@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
	<4A5DED16.2080407@gmx.de>
	<4A5DEDDC.8070106@sun.com> <4A5E04AF.2010302@gmx.de>
	<4A5E13B1.6080406@sun.com> <4A5E1984.3070004@gmx.de>
Message-ID: <4A5E2110.6030705@sun.com>



Ulf Zibis wrote:
> Am 15.07.2009 19:36, Lance J. Andersen schrieb:
>>
>>
>> Ulf Zibis wrote:
>>
>>> But does this script help me, to have an account on webrev server ?
>> There is no webrev server,
>
> I just referred to http://cr.openjdk.java.net/ :
>
>
>     General
>
> _This server_ provides storage and display of code review materials 
> such as webrevs and other artifacts related to the OpenJDK 
> <http://openjdk.java.net/> Community. If you are interested in 
> monitoring recent reviews, try our review feed here 
> <http://cr.openjdk.java.net/feed.atom>.
>
> Any user with push access to the OpenJDK Mercurial 
> <http://hg.openjdk.java.net> server can publish materials on _this 
> server_. Users can upload files to temporary storage using secure 
> methods (rsync, scp, and sftp).
>

If you have push access to the  workspace, you should be able to  to do 
this now.  I have not tried it myself, but if you have problems, just 
create a zip of the webrev directory and include it with your review 
request email or just email it to whomever has volunteered to review.
>
>
>>>
>>> ... and what does this script do? Does it open a GUI where I can enter
>>> the mercurial changeset to upload?
>> The script will create a set of diffs which you can view easily in a 
>> web browser.  Much easier to read than a standard diff.
>
> OK, thanks. Is there any tutorial for best practice of this script. 
> Should it be started in same folder as local .hg repository?
> But anyway, I still need an account on your whatever server to publish 
> those set of diffs.

There is not tutorial outside of the blog that I know of but this should 
get you started http://blogs.sun.com/jcc/date/20080211

It is really pretty straightforward, it will create a directory with the 
generated html files of your changes... I believe some versions might 
create a zip for you of your webrev.

hth

-lance
>
> -Ulf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090715/db546549/attachment.html>

From joe.darcy at sun.com  Wed Jul 15 19:17:18 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Wed, 15 Jul 2009 19:17:18 +0000
Subject: hg: jdk7/tl/jdk: 6857789: (reflect) Create common superclass of
	reflective exceptions
Message-ID: <20090715191803.BF389E1BB@hg.openjdk.java.net>

Changeset: aaf0cb20646e
Author:    darcy
Date:      2009-07-15 12:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aaf0cb20646e

6857789: (reflect) Create common superclass of reflective exceptions
Reviewed-by: martin

! src/share/classes/java/lang/ClassNotFoundException.java
! src/share/classes/java/lang/IllegalAccessException.java
! src/share/classes/java/lang/InstantiationException.java
! src/share/classes/java/lang/NoSuchFieldException.java
! src/share/classes/java/lang/NoSuchMethodException.java
+ src/share/classes/java/lang/ReflectiveOperationException.java
! src/share/classes/java/lang/reflect/InvocationTargetException.java



From Joe.Darcy at Sun.COM  Wed Jul 15 20:30:13 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Wed, 15 Jul 2009 13:30:13 -0700
Subject: Code review request for 6463998: Undocumented NullPointerExeption from
	Float.parseFloat and Double.parseDouble
Message-ID: <4A5E3C55.2050908@sun.com>

Hello.

Please review this simple patch below to document the long-standing 
behavior of parseFloat and parseDouble regarding null inputs.  (Yes, the 
various string -> value methods have inconsistent behavior with respect 
to null inputs; however, at this point the safest course of action is 
just to document the present behavior.)

Thanks,

-Joe

--- old/src/share/classes/java/lang/Double.java    2009-07-15 
13:28:38.000000000 -0700
+++ new/src/share/classes/java/lang/Double.java    2009-07-15 
13:28:38.000000000 -0700
@@ -529,6 +529,7 @@
      * @param  s   the string to be parsed.
      * @return the {@code double} value represented by the string
      *         argument.
+     * @throws  NullPointerException if the argument string is null
      * @throws NumberFormatException if the string does not contain
      *         a parsable {@code double}.
      * @see    java.lang.Double#valueOf(String)
--- old/src/share/classes/java/lang/Float.java    2009-07-15 
13:28:39.000000000 -0700
+++ new/src/share/classes/java/lang/Float.java    2009-07-15 
13:28:39.000000000 -0700
@@ -441,6 +441,7 @@
      * @param      s   the string to be parsed.
      * @return the {@code float} value represented by the string
      *         argument.
+     * @throws  NullPointerException if the argument string is null
      * @throws  NumberFormatException  if the string does not contain a
      *               parsable {@code float}.
      * @see        java.lang.Float#valueOf(String)


From Lance.Andersen at Sun.COM  Wed Jul 15 21:01:25 2009
From: Lance.Andersen at Sun.COM (Lance J. Andersen)
Date: Wed, 15 Jul 2009 17:01:25 -0400
Subject: Code review request for 6463998: Undocumented NullPointerExeption
	from	Float.parseFloat and Double.parseDouble
In-Reply-To: <4A5E3C55.2050908@sun.com>
References: <4A5E3C55.2050908@sun.com>
Message-ID: <4A5E43A5.2090909@sun.com>

Looks good Joe

-Lance

Joseph D. Darcy wrote:
> Hello.
>
> Please review this simple patch below to document the long-standing 
> behavior of parseFloat and parseDouble regarding null inputs.  (Yes, 
> the various string -> value methods have inconsistent behavior with 
> respect to null inputs; however, at this point the safest course of 
> action is just to document the present behavior.)
>
> Thanks,
>
> -Joe
>
> --- old/src/share/classes/java/lang/Double.java    2009-07-15 
> 13:28:38.000000000 -0700
> +++ new/src/share/classes/java/lang/Double.java    2009-07-15 
> 13:28:38.000000000 -0700
> @@ -529,6 +529,7 @@
>      * @param  s   the string to be parsed.
>      * @return the {@code double} value represented by the string
>      *         argument.
> +     * @throws  NullPointerException if the argument string is null
>      * @throws NumberFormatException if the string does not contain
>      *         a parsable {@code double}.
>      * @see    java.lang.Double#valueOf(String)
> --- old/src/share/classes/java/lang/Float.java    2009-07-15 
> 13:28:39.000000000 -0700
> +++ new/src/share/classes/java/lang/Float.java    2009-07-15 
> 13:28:39.000000000 -0700
> @@ -441,6 +441,7 @@
>      * @param      s   the string to be parsed.
>      * @return the {@code float} value represented by the string
>      *         argument.
> +     * @throws  NullPointerException if the argument string is null
>      * @throws  NumberFormatException  if the string does not contain a
>      *               parsable {@code float}.
>      * @see        java.lang.Float#valueOf(String)


From ariel at weisberg.ws  Wed Jul 15 19:24:12 2009
From: ariel at weisberg.ws (Ariel Weisberg)
Date: Wed, 15 Jul 2009 15:24:12 -0400
Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
In-Reply-To: <1247540368.18990.1324916035@webmail.messagingengine.com>
References: <NFBBKALFDCPFIDBNKAPCAEJGICAA.davidcholmes@aapt.net.au>
	<1247540368.18990.1324916035@webmail.messagingengine.com>
Message-ID: <1247685852.19957.1325194693@webmail.messagingengine.com>

Hi,

I have found that there are two different failure modes without
involving -XX:+UseMembar. There is the LBD deadlock and then
there is the dead socket in between two nodes. Either failure can
occur with the same code and settings. It appears that the dead
socket problem is more common. The LBD failure is also not
correlated with any specific LBD (originally saw it with only the
LBD for an Initiator's mailbox).

With -XX:+UseMembar the system is noticeably more reliable and
tends to run much longer without failing (although it can still
fail immediately). When it does fail it has been due to a dead
connection. I have not reproduced a deadlock on an LBD with
-XX:+UseMembar.

I also found that the dead socket issue was reproducible twice on
Dell Poweredge 2970s (two socket AMD). It takes an hour or so to
reproduce the dead socket problem on the 2970. I have not
recreated the LBD issue on them although given how difficult the
socket issue is to reproduce it may be that I have not run them
long enough. On the AMD machines I did not use -XX:+UseMembar.

Ariel

On Mon, 13 Jul 2009 18:59 -0400, "Ariel Weisberg"
<ariel at weisberg.ws> wrote:

Hi all.

Sorry Martin I missed reading your last email. I am not confident
that I will get a small reproducible test case in a reasonable
time frame. Reproducing it with the application is easy and I
will see what I can do about getting the source available.

One interesting thing I can tell you is that if I remove the
LinkedBlockingDeque from the mailbox of the Initiator the system
still deadlocks. The cluster has a TCP mesh topology so any node
can deliver messages to any other node. One of the connections
goes dead and neither side detects that there is a problem. I add
some assertions to the network selection thread to check that all
the connections in the cluster are still healthy and assert that
they have the correct interests set.

Here are the things it checks for  to make sure each connection
is working:
>                             for (ForeignHost.Port port :
foreignHostPorts) {
>
assert(port.m_selectionKey.isValid());
>
assert(port.m_selectionKey.selector() == m_selector);
>                             assert(port.m_channel.isOpen());
>
assert(((SocketChannel)port.m_channel).isConnected());
>
assert(((SocketChannel)port.m_channel).socket().isInputShutdown()
== false);
>
assert(((SocketChannel)port.m_channel).socket().isOutputShutdown(
) == false);
>
assert(((SocketChannel)port.m_channel).isOpen());
>
assert(((SocketChannel)port.m_channel).isRegistered());
>
assert(((SocketChannel)port.m_channel).keyFor(m_selector) !=
null);
>
assert(((SocketChannel)port.m_channel).keyFor(m_selector) ==
port.m_selectionKey);
>                             if
(m_selector.selectedKeys().contains(port.m_selectionKey)) {
>
assert((port.m_selectionKey.interestOps() & SelectionKey.OP_READ)
!= 0);
>
assert((port.m_selectionKey.interestOps() &
SelectionKey.OP_WRITE) != 0);
>                             } else {
>                                 if (port.isRunning()) {
>
assert(port.m_selectionKey.interestOps() == 0);
>                                 } else {
>
port.m_selectionKey.interestOps(SelectionKey.OP_READ |
SelectionKey.OP_WRITE);
>                                     assert((port.interestOps()
& SelectionKey.OP_READ) != 0);
>                                     assert((port.interestOps()
& SelectionKey.OP_WRITE) != 0);
>                                 }
>                             }
>                             assert(m_selector.isOpen());
>
assert(m_selector.keys().contains(port.m_selectionKey));
OP_READ | OP_WRITE is set as the interest ops every time through,
and there is no other code that changes the interest ops during
execution. The application will run for a while and then one of
the connections will stop being selected on both sides. If I step
in with the debugger on either side everything looks correct. The
keys have the correct interest ops and the selectors have the
keys in their key set.

What I suspect is happening is that a bug on one node stops the
socket from being selected (for both read and write), and
eventually the socket fills up and can't be written to by the
other side.

If I can get my VPN access together tomorrow I will run with
-XX:+UseMembar and also try running on some 8-core AMD machines.
Otherwise I will have to get to it Wednesday.

Thanks,

Ariel Weisberg


On Tue, 14 Jul 2009 05:00 +1000, "David Holmes"
<davidcholmes at aapt.net.au> wrote:

Martin,



I don't think this is due to LBQ/D. This is looking similar to a
couple of other ReentrantLock/AQS "lost wakeup" hangs that I've
got on the radar. We have a reprodeucible test case for one issue
but it only fails on one kind of system - x4450. I'm on vacation
most of this week but will try and get back to this next week.



Ariel: one thing to try please see if -XX:+UseMembar fixes the
problem.



Thanks,

David Holmes

-----Original Message-----
From: Martin Buchholz [mailto:martinrb at google.com]
Sent: Tuesday, 14 July 2009 8:38 AM
To: Ariel Weisberg
Cc: davidcholmes at aapt.net.au; core-libs-dev;
concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] LinkedBlockingDeque deadlock?

  I did some stack trace eyeballing and did a mini-audit of the
  LinkedBlockingDeque code, with a view to finding possible
  bugs,
  and came up empty.  Maybe it's a deep bug in hotspot?
  Ariel, it would be good if you could get a reproducible test
  case soonish,
  while someone on the planet has the motivation and familiarity
  to fix it.
  In another month I may disavow all knowledge of
  j.u.c.*Blocking*
  Martin

On Wed, Jul 8, 2009 at 15:57, Ariel Weisberg
<[1]ariel at weisberg.ws> wrote:

  Hi,

> The poll()ing thread is blocked waiting for the internal lock,
but
> there's
> no indication of any thread owning that lock. You're using an
OpenJDK 6
> build ... can you try JDK7 ?


  I got a chance to do that today. I downloaded JDK 7 from
  [2]http://www.java.net/download/jdk7/binaries/jdk-7-ea-bin-b63
  -linux-x64-02_jul_2009.bin
  and was able to reproduce the problem. I have attached the
  stack trace
  from running the 1.7 version. It is the same situation as
  before except
  there are 9 execution sites running on each host. There are no
  threads
  that are missing or that have been restarted. Foo Network
  thread
  (selector thread) and Network Thread - 0 are waiting on
  0x00002aaab43d3b28. I also ran with JDK 7 and 6 and
  LinkedBlockingQueue
  and was not able to recreate the problem using that structure.

> I don't recall anything similar to this, but I don't know what
version
> that
> OpenJDK6 build relates to.


  The cluster is running on CentOS 5.3.
  >[aweisberg at 3f ~]$ rpm -qi
  java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5
  >Name        : java-1.6.0-openjdk           Relocations: (not
  relocatable)
  >Version     : 1.6.0.0                           Vendor:
  CentOS
  >Release     : 0.30.b09.el5                  Build Date: Tue
  07 Apr 2009 07:24:52 PM EDT
  >Install Date: Thu 11 Jun 2009 03:27:46 PM EDT      Build
  Host: [3]builder10.centos.org
  >Group       : Development/Languages         Source RPM:
  java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5.src.rpm
  >Size        : 76336266                         License: GPLv2
  with exceptions
  >Signature   : DSA/SHA1, Wed 08 Apr 2009 07:55:13 AM EDT, Key
  ID a8a447dce8562897
  >URL         : [4]http://icedtea.classpath.org/
  >Summary     : OpenJDK Runtime Environment
  >Description :
  >The OpenJDK runtime environment.

> Make sure you haven't missed any exceptions occurring in other
threads.

  There are no threads missing in the application (terminated
  threads are
  not replaced) and there is a try catch pair (prints error and
  rethrows)
  around the run loop of each thread. It is possible that an
  exception may
  have been swallowed up somewhere.

>A small reproducible test case from you would be useful.

  I am working on that. I wrote a test case that mimics the
  application's
  use of the LBD, but I have not succeeded in reproducing the
  problem in
  the test case. The app has a single thread (network selector)
  that polls
  the LBD and several threads (ExecutionSites, and network
  threads that
  return results from remote ExecutionSites) that offer results
  into the
  queue. About 120k items will go into/out of the deque each
  second. In
  the actual app the problem is reproducible but inconsistent.
  If I run on
  my dual core laptop I can't reproduce it, and it is less
  likely to occur
  with a small cluster, but with 6 nodes (~560k
  transactions/sec) the
  problem will usually appear. Sometimes the cluster will run
  for several
  minutes without issue and other times it will deadlock
  immediately.
  Thanks,
  Ariel

On Wed, 08 Jul 2009 05:14 +1000, "Martin Buchholz"
<[5]martinrb at google.com> wrote:
>[+core-libs-dev]
>
>Doug Lea and I are (slowly) working on a new version of
LinkedBlockingDeque.
>I was not aware of a deadlock but can vaguely imagine how it
might happen.
>A small reproducible test case from you would be useful.
>
>Unfinished work in progress can be found here:
>[6]http://cr.openjdk.java.net/~martin/webrevs/openjdk7/BlockingQ
ueue/
>
>Martin


  On Wed, 08 Jul 2009 05:14 +1000, "David Holmes"

<[7]davidcholmes at aapt.net.au> wrote:
>


> Ariel,
>
> The poll()ing thread is blocked waiting for the internal lock,
but
> there's
> no indication of any thread owning that lock. You're using an
OpenJDK 6
> build ... can you try JDK7 ?
>
> I don't recall anything similar to this, but I don't know what
version
> that
> OpenJDK6 build relates to.
>
> Make sure you haven't missed any exceptions occurring in other
threads.
>
> David Holmes
>
> > -----Original Message-----
> > From: [8]concurrency-interest-bounces at cs.oswego.edu
> > [mailto:[9]concurrency-interest-bounces at cs.oswego.edu]On
Behalf Of Ariel
> > Weisberg
> > Sent: Wednesday, 8 July 2009 8:31 AM
> > To: [10]concurrency-interest at cs.oswego.edu
> > Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
> >
> >
> > Hi all,
> >
> > I did a search on LinkedBlockingDeque and didn't find
anything similar
> > to what I am seeing. Attached is the stack trace from an
application
> > that is deadlocked with three threads waiting for
0x00002aaab3e91080
> > (threads "ExecutionSite: 26", "ExecutionSite:27", and
"Network
> > Selector"). The execution sites are attempting to offer
results to the
> > deque and the network thread is trying to poll for them using
the
> > non-blocking version of poll. I am seeing the network thread
never
> > return from poll (straight poll()). Do my eyes deceive me?
> >
> > Thanks,
> >
> > Ariel Weisberg
> >
>

References

1. mailto:ariel at weisberg.ws
2. http://www.java.net/download/jdk7/binaries/jdk-7-ea-bin-b63-linux-x64-02_jul_2009.bin
3. http://builder10.centos.org/
4. http://icedtea.classpath.org/
5. mailto:martinrb at google.com
6. http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/BlockingQueue/
7. mailto:davidcholmes at aapt.net.au
8. mailto:concurrency-interest-bounces at cs.oswego.edu
9. mailto:concurrency-interest-bounces at cs.oswego.edu
  10. mailto:concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090715/661cfa4c/attachment.html>

From martinrb at google.com  Wed Jul 15 21:24:32 2009
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 15 Jul 2009 14:24:32 -0700
Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
In-Reply-To: <1247685852.19957.1325194693@webmail.messagingengine.com>
References: <NFBBKALFDCPFIDBNKAPCAEJGICAA.davidcholmes@aapt.net.au>
	<1247540368.18990.1324916035@webmail.messagingengine.com>
	<1247685852.19957.1325194693@webmail.messagingengine.com>
Message-ID: <1ccfd1c10907151424t2f835a29y80a10228e0bc66c0@mail.gmail.com>

In summary,
there are two different bugs at work here,
and neither of them is in LBD.
The hotspot team is working on the LBD deadlock.
(As always) It would be good to have a good test case for
the dead socket problem.

Martin

On Wed, Jul 15, 2009 at 12:24, Ariel Weisberg <ariel at weisberg.ws> wrote:

> Hi,
>
> I have found that there are two different failure modes without involving
> -XX:+UseMembar. There is the LBD deadlock and then there is the dead socket
> in between two nodes. Either failure can occur with the same code and
> settings. It appears that the dead socket problem is more common. The LBD
> failure is also not correlated with any specific LBD (originally saw it with
> only the LBD for an Initiator's mailbox).
>
> With -XX:+UseMembar the system is noticeably more reliable and tends to run
> much longer without failing (although it can still fail immediately). When
> it does fail it has been due to a dead connection. I have not reproduced a
> deadlock on an LBD with -XX:+UseMembar.
>
> I also found that the dead socket issue was reproducible twice on Dell
> Poweredge 2970s (two socket AMD). It takes an hour or so to reproduce the
> dead socket problem on the 2970. I have not recreated the LBD issue on them
> although given how difficult the socket issue is to reproduce it may be that
> I have not run them long enough. On the AMD machines I did not use
> -XX:+UseMembar.
>
> Ariel
>
> On Mon, 13 Jul 2009 18:59 -0400, "Ariel Weisberg" <ariel at weisberg.ws>
> wrote:
>
>  Hi all.
>
> Sorry Martin I missed reading your last email. I am not confident that I
> will get a small reproducible test case in a reasonable time frame.
> Reproducing it with the application is easy and I will see what I can do
> about getting the source available.
>
> One interesting thing I can tell you is that if I remove the
> LinkedBlockingDeque from the mailbox of the Initiator the system still
> deadlocks. The cluster has a TCP mesh topology so any node can deliver
> messages to any other node. One of the connections goes dead and neither
> side detects that there is a problem. I add some assertions to the network
> selection thread to check that all the connections in the cluster are still
> healthy and assert that they have the correct interests set.
>
> Here are the things it checks for  to make sure each connection is working:
> >                             for (ForeignHost.Port port :
> foreignHostPorts) {
> >                             assert(port.m_selectionKey.isValid());
> >                             assert(port.m_selectionKey.selector() ==
> m_selector);
> >                             assert(port.m_channel.isOpen());
> >
> assert(((SocketChannel)port.m_channel).isConnected());
> >
> assert(((SocketChannel)port.m_channel).socket().isInputShutdown() == false);
> >
> assert(((SocketChannel)port.m_channel).socket().isOutputShutdown() ==
> false);
> >
> assert(((SocketChannel)port.m_channel).isOpen());
> >
> assert(((SocketChannel)port.m_channel).isRegistered());
> >
> assert(((SocketChannel)port.m_channel).keyFor(m_selector) != null);
> >
> assert(((SocketChannel)port.m_channel).keyFor(m_selector) ==
> port.m_selectionKey);
> >                             if
> (m_selector.selectedKeys().contains(port.m_selectionKey)) {
> >                                 assert((port.m_selectionKey.interestOps()
> & SelectionKey.OP_READ) != 0);
> >                                 assert((port.m_selectionKey.interestOps()
> & SelectionKey.OP_WRITE) != 0);
> >                             } else {
> >                                 if (port.isRunning()) {
> >
> assert(port.m_selectionKey.interestOps() == 0);
> >                                 } else {
> >
> port.m_selectionKey.interestOps(SelectionKey.OP_READ |
> SelectionKey.OP_WRITE);
> >                                     assert((port.interestOps() &
> SelectionKey.OP_READ) != 0);
> >                                     assert((port.interestOps() &
> SelectionKey.OP_WRITE) != 0);
> >                                 }
> >                             }
> >                             assert(m_selector.isOpen());
> >
> assert(m_selector.keys().contains(port.m_selectionKey));
> OP_READ | OP_WRITE is set as the interest ops every time through, and there
> is no other code that changes the interest ops during execution. The
> application will run for a while and then one of the connections will stop
> being selected on both sides. If I step in with the debugger on either side
> everything looks correct. The keys have the correct interest ops and the
> selectors have the keys in their key set.
>
> What I suspect is happening is that a bug on one node stops the socket from
> being selected (for both read and write), and eventually the socket fills up
> and can't be written to by the other side.
>
> If I can get my VPN access together tomorrow I will run with -XX:+UseMembar
> and also try running on some 8-core AMD machines. Otherwise I will have to
> get to it Wednesday.
>
> Thanks,
>
> Ariel Weisberg
>
>
> On Tue, 14 Jul 2009 05:00 +1000, "David Holmes" <davidcholmes at aapt.net.au>
> wrote:
>
> Martin,
>
> I don't think this is due to LBQ/D. This is looking similar to a couple of
> other ReentrantLock/AQS "lost wakeup" hangs that I've got on the radar. We
> have a reprodeucible test case for one issue but it only fails on one kind
> of system - x4450. I'm on vacation most of this week but will try and get
> back to this next week.
>
> Ariel: one thing to try please see if -XX:+UseMembar fixes the problem.
>
> Thanks,
> David Holmes
>
> -----Original Message-----
> *From:* Martin Buchholz [mailto:martinrb at google.com]
> *Sent:* Tuesday, 14 July 2009 8:38 AM
> *To:* Ariel Weisberg
> *Cc:* davidcholmes at aapt.net.au; core-libs-dev;
> concurrency-interest at cs.oswego.edu
> *Subject:* Re: [concurrency-interest] LinkedBlockingDeque deadlock?
>
>  I did some stack trace eyeballing and did a mini-audit of the
> LinkedBlockingDeque code, with a view to finding possible bugs,
> and came up empty.  Maybe it's a deep bug in hotspot?
>
> Ariel, it would be good if you could get a reproducible test case soonish,
> while someone on the planet has the motivation and familiarity to fix it.
> In another month I may disavow all knowledge of j.u.c.*Blocking*
>
> Martin
>
>
> On Wed, Jul 8, 2009 at 15:57, Ariel Weisberg <ariel at weisberg.ws> wrote:
>
>> Hi,
>>
>> > The poll()ing thread is blocked waiting for the internal lock, but
>> > there's
>> > no indication of any thread owning that lock. You're using an OpenJDK 6
>> > build ... can you try JDK7 ?
>>
>> I got a chance to do that today. I downloaded JDK 7 from
>>
>> http://www.java.net/download/jdk7/binaries/jdk-7-ea-bin-b63-linux-x64-02_jul_2009.bin
>> and was able to reproduce the problem. I have attached the stack trace
>> from running the 1.7 version. It is the same situation as before except
>> there are 9 execution sites running on each host. There are no threads
>> that are missing or that have been restarted. Foo Network thread
>> (selector thread) and Network Thread - 0 are waiting on
>> 0x00002aaab43d3b28. I also ran with JDK 7 and 6 and LinkedBlockingQueue
>> and was not able to recreate the problem using that structure.
>>
>> > I don't recall anything similar to this, but I don't know what version
>> > that
>> > OpenJDK6 build relates to.
>>
>> The cluster is running on CentOS 5.3.
>> >[aweisberg at 3f ~]$ rpm -qi java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5
>> >Name        : java-1.6.0-openjdk           Relocations: (not relocatable)
>> >Version     : 1.6.0.0                           Vendor: CentOS
>> >Release     : 0.30.b09.el5                  Build Date: Tue 07 Apr 2009
>> 07:24:52 PM EDT
>> >Install Date: Thu 11 Jun 2009 03:27:46 PM EDT      Build Host:
>> builder10.centos.org
>> >Group       : Development/Languages         Source RPM:
>> java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5.src.rpm
>> >Size        : 76336266                         License: GPLv2 with
>> exceptions
>> >Signature   : DSA/SHA1, Wed 08 Apr 2009 07:55:13 AM EDT, Key ID
>> a8a447dce8562897
>> >URL         : http://icedtea.classpath.org/
>> >Summary     : OpenJDK Runtime Environment
>> >Description :
>> >The OpenJDK runtime environment.
>>
>> > Make sure you haven't missed any exceptions occurring in other threads.
>> There are no threads missing in the application (terminated threads are
>> not replaced) and there is a try catch pair (prints error and rethrows)
>> around the run loop of each thread. It is possible that an exception may
>> have been swallowed up somewhere.
>>
>> >A small reproducible test case from you would be useful.
>> I am working on that. I wrote a test case that mimics the application's
>> use of the LBD, but I have not succeeded in reproducing the problem in
>> the test case. The app has a single thread (network selector) that polls
>> the LBD and several threads (ExecutionSites, and network threads that
>> return results from remote ExecutionSites) that offer results into the
>> queue. About 120k items will go into/out of the deque each second. In
>> the actual app the problem is reproducible but inconsistent. If I run on
>> my dual core laptop I can't reproduce it, and it is less likely to occur
>> with a small cluster, but with 6 nodes (~560k transactions/sec) the
>> problem will usually appear. Sometimes the cluster will run for several
>> minutes without issue and other times it will deadlock immediately.
>>
>> Thanks,
>>
>> Ariel
>>
>> On Wed, 08 Jul 2009 05:14 +1000, "Martin Buchholz"
>> <martinrb at google.com> wrote:
>> >[+core-libs-dev]
>> >
>> >Doug Lea and I are (slowly) working on a new version of
>> LinkedBlockingDeque.
>> >I was not aware of a deadlock but can vaguely imagine how it might
>> happen.
>> >A small reproducible test case from you would be useful.
>> >
>> >Unfinished work in progress can be found here:
>> >http://cr.openjdk.java.net/~martin/webrevs/openjdk7/BlockingQueue/<http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/BlockingQueue/>
>> >
>> >Martin
>>
>> On Wed, 08 Jul 2009 05:14 +1000, "David Holmes"
>> <davidcholmes at aapt.net.au> wrote:
>> >
>>
>> > Ariel,
>> >
>> > The poll()ing thread is blocked waiting for the internal lock, but
>> > there's
>> > no indication of any thread owning that lock. You're using an OpenJDK 6
>> > build ... can you try JDK7 ?
>> >
>> > I don't recall anything similar to this, but I don't know what version
>> > that
>> > OpenJDK6 build relates to.
>> >
>> > Make sure you haven't missed any exceptions occurring in other threads.
>> >
>> > David Holmes
>> >
>> > > -----Original Message-----
>> > > From: concurrency-interest-bounces at cs.oswego.edu
>> > > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Ariel
>> > > Weisberg
>> > > Sent: Wednesday, 8 July 2009 8:31 AM
>> > > To: concurrency-interest at cs.oswego.edu
>> > > Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
>> > >
>> > >
>> > > Hi all,
>> > >
>> > > I did a search on LinkedBlockingDeque and didn't find anything similar
>> > > to what I am seeing. Attached is the stack trace from an application
>> > > that is deadlocked with three threads waiting for 0x00002aaab3e91080
>> > > (threads "ExecutionSite: 26", "ExecutionSite:27", and "Network
>> > > Selector"). The execution sites are attempting to offer results to the
>> > > deque and the network thread is trying to poll for them using the
>> > > non-blocking version of poll. I am seeing the network thread never
>> > > return from poll (straight poll()). Do my eyes deceive me?
>> > >
>> > > Thanks,
>> > >
>> > > Ariel Weisberg
>> > >
>> >
>>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090715/6834e8c9/attachment.html>

From Joe.Darcy at Sun.COM  Wed Jul 15 21:39:11 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Wed, 15 Jul 2009 14:39:11 -0700
Subject: Code review request for 6463998: Undocumented NullPointerExeption
	from	Float.parseFloat and Double.parseDouble
In-Reply-To: <4A5E43A5.2090909@sun.com>
References: <4A5E3C55.2050908@sun.com> <4A5E43A5.2090909@sun.com>
Message-ID: <4A5E4C7F.1060006@sun.com>

Hello.

In response to a suggestion from Iris, I'll change the patch to use the 
phrase "the string" for both exceptions @throws descriptions.

Thanks for the quick reviews,

-Joe

Lance J. Andersen wrote:
> Looks good Joe
>
> -Lance
>
> Joseph D. Darcy wrote:
>> Hello.
>>
>> Please review this simple patch below to document the long-standing 
>> behavior of parseFloat and parseDouble regarding null inputs.  (Yes, 
>> the various string -> value methods have inconsistent behavior with 
>> respect to null inputs; however, at this point the safest course of 
>> action is just to document the present behavior.)
>>
>> Thanks,
>>
>> -Joe
>>
>> --- old/src/share/classes/java/lang/Double.java    2009-07-15 
>> 13:28:38.000000000 -0700
>> +++ new/src/share/classes/java/lang/Double.java    2009-07-15 
>> 13:28:38.000000000 -0700
>> @@ -529,6 +529,7 @@
>>      * @param  s   the string to be parsed.
>>      * @return the {@code double} value represented by the string
>>      *         argument.
>> +     * @throws  NullPointerException if the argument string is null
>>      * @throws NumberFormatException if the string does not contain
>>      *         a parsable {@code double}.
>>      * @see    java.lang.Double#valueOf(String)
>> --- old/src/share/classes/java/lang/Float.java    2009-07-15 
>> 13:28:39.000000000 -0700
>> +++ new/src/share/classes/java/lang/Float.java    2009-07-15 
>> 13:28:39.000000000 -0700
>> @@ -441,6 +441,7 @@
>>      * @param      s   the string to be parsed.
>>      * @return the {@code float} value represented by the string
>>      *         argument.
>> +     * @throws  NullPointerException if the argument string is null
>>      * @throws  NumberFormatException  if the string does not contain a
>>      *               parsable {@code float}.
>>      * @see        java.lang.Float#valueOf(String)



From joe.darcy at sun.com  Wed Jul 15 21:49:06 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Wed, 15 Jul 2009 21:49:06 +0000
Subject: hg: jdk7/tl/jdk: 6463998: Undocumented NullPointerExeption from
	Float.parseFloat and Double.parseDouble
Message-ID: <20090715214945.89296E220@hg.openjdk.java.net>

Changeset: 2a1b1075f583
Author:    darcy
Date:      2009-07-15 14:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2a1b1075f583

6463998: Undocumented NullPointerExeption from Float.parseFloat and Double.parseDouble
Reviewed-by: lancea, iris

! src/share/classes/java/lang/Double.java
! src/share/classes/java/lang/Float.java



From David.Holmes at Sun.COM  Thu Jul 16 05:28:02 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Thu, 16 Jul 2009 15:28:02 +1000
Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
In-Reply-To: <1ccfd1c10907151424t2f835a29y80a10228e0bc66c0@mail.gmail.com>
References: <NFBBKALFDCPFIDBNKAPCAEJGICAA.davidcholmes@aapt.net.au>
	<1247540368.18990.1324916035@webmail.messagingengine.com>
	<1247685852.19957.1325194693@webmail.messagingengine.com>
	<1ccfd1c10907151424t2f835a29y80a10228e0bc66c0@mail.gmail.com>
Message-ID: <4A5EBA62.8000802@sun.com>

Just to clarify ...

Martin Buchholz said the following on 07/16/09 07:24:
> In summary,
> there are two different bugs at work here,
> and neither of them is in LBD.
> The hotspot team is working on the LBD deadlock.

Not the "hotspot team", just me :) - I am looking into this in my role 
as j.u.c evaluator. Given the difficulty in reproducing this issue 
in-house, progress is very slow. It will be a while before I can 
determine whether this is a bug in AQS code, or whether there is 
something bad happening with regard to memory ordering/visibility on 
some systems.

Cheers,
David Holmes

> (As always) It would be good to have a good test case for
> the dead socket problem.
> 
> Martin
> 
> On Wed, Jul 15, 2009 at 12:24, Ariel Weisberg <ariel at weisberg.ws 
> <mailto:ariel at weisberg.ws>> wrote:
> 
>     Hi,
>      
>     I have found that there are two different failure modes without
>     involving -XX:+UseMembar. There is the LBD deadlock and then there
>     is the dead socket in between two nodes. Either failure can occur
>     with the same code and settings. It appears that the dead socket
>     problem is more common. The LBD failure is also not correlated with
>     any specific LBD (originally saw it with only the LBD for an
>     Initiator's mailbox).
>      
>     With -XX:+UseMembar the system is noticeably more reliable and tends
>     to run much longer without failing (although it can still fail
>     immediately). When it does fail it has been due to a dead
>     connection. I have not reproduced a deadlock on an LBD with
>     -XX:+UseMembar.
>      
>     I also found that the dead socket issue was reproducible twice on
>     Dell Poweredge 2970s (two socket AMD). It takes an hour or so to
>     reproduce the dead socket problem on the 2970. I have not recreated
>     the LBD issue on them although given how difficult the socket issue
>     is to reproduce it may be that I have not run them long enough. On
>     the AMD machines I did not use -XX:+UseMembar.
>      
>     Ariel
>      
>     On Mon, 13 Jul 2009 18:59 -0400, "Ariel Weisberg" <ariel at weisberg.ws
>     <mailto:ariel at weisberg.ws>> wrote:
>>     Hi all.
>>      
>>     Sorry Martin I missed reading your last email. I am not confident
>>     that I will get a small reproducible test case in a reasonable
>>     time frame. Reproducing it with the application is easy and I will
>>     see what I can do about getting the source available.
>>      
>>     One interesting thing I can tell you is that if I remove the
>>     LinkedBlockingDeque from the mailbox of the Initiator the system
>>     still deadlocks. The cluster has a TCP mesh topology so any node
>>     can deliver messages to any other node. One of the connections
>>     goes dead and neither side detects that there is a problem. I add
>>     some assertions to the network selection thread to check that all
>>     the connections in the cluster are still healthy and assert that
>>     they have the correct interests set.
>>      
>>     Here are the things it checks for  to make sure each connection is
>>     working:
>>     >                             for (ForeignHost.Port port :
>>     foreignHostPorts) {
>>     >                             assert(port.m_selectionKey.isValid());
>>     >                            
>>     assert(port.m_selectionKey.selector() == m_selector);
>>     >                             assert(port.m_channel.isOpen());
>>     >                            
>>     assert(((SocketChannel)port.m_channel).isConnected());
>>     >                            
>>     assert(((SocketChannel)port.m_channel).socket().isInputShutdown()
>>     == false);
>>     >                            
>>     assert(((SocketChannel)port.m_channel).socket().isOutputShutdown()
>>     == false);
>>     >                            
>>     assert(((SocketChannel)port.m_channel).isOpen());
>>     >                            
>>     assert(((SocketChannel)port.m_channel).isRegistered());
>>     >                            
>>     assert(((SocketChannel)port.m_channel).keyFor(m_selector) != null);
>>     >                            
>>     assert(((SocketChannel)port.m_channel).keyFor(m_selector) ==
>>     port.m_selectionKey);
>>     >                             if
>>     (m_selector.selectedKeys().contains(port.m_selectionKey)) {
>>     >                                
>>     assert((port.m_selectionKey.interestOps() & SelectionKey.OP_READ)
>>     != 0);
>>     >                                
>>     assert((port.m_selectionKey.interestOps() & SelectionKey.OP_WRITE)
>>     != 0);
>>     >                             } else {
>>     >                                 if (port.isRunning()) {
>>     >                                    
>>     assert(port.m_selectionKey.interestOps() == 0);
>>     >                                 } else {
>>     >                                    
>>     port.m_selectionKey.interestOps(SelectionKey.OP_READ |
>>     SelectionKey.OP_WRITE);
>>     >                                     assert((port.interestOps() &
>>     SelectionKey.OP_READ) != 0);
>>     >                                     assert((port.interestOps() &
>>     SelectionKey.OP_WRITE) != 0);
>>     >                                 }
>>     >                             }
>>     >                             assert(m_selector.isOpen());
>>     >                            
>>     assert(m_selector.keys().contains(port.m_selectionKey));
>>     OP_READ | OP_WRITE is set as the interest ops every time through,
>>     and there is no other code that changes the interest ops during
>>     execution. The application will run for a while and then one of
>>     the connections will stop being selected on both sides. If I step
>>     in with the debugger on either side everything looks correct. The
>>     keys have the correct interest ops and the selectors have the keys
>>     in their key set.
>>      
>>     What I suspect is happening is that a bug on one node stops the
>>     socket from being selected (for both read and write), and
>>     eventually the socket fills up and can't be written to by the
>>     other side.
>>      
>>     If I can get my VPN access together tomorrow I will run with
>>     -XX:+UseMembar and also try running on some 8-core AMD machines.
>>     Otherwise I will have to get to it Wednesday.
>>      
>>     Thanks,
>>      
>>     Ariel Weisberg
>>      
>>      
>>     On Tue, 14 Jul 2009 05:00 +1000, "David Holmes"
>>     <davidcholmes at aapt.net.au <mailto:davidcholmes at aapt.net.au>> wrote:
>>>     Martin,
>>>      
>>>     I don't think this is due to LBQ/D. This is looking similar to a
>>>     couple of other ReentrantLock/AQS "lost wakeup" hangs that I've
>>>     got on the radar. We have a reprodeucible test case for one issue
>>>     but it only fails on one kind of system - x4450. I'm on vacation
>>>     most of this week but will try and get back to this next week.
>>>      
>>>     Ariel: one thing to try please see if -XX:+UseMembar fixes the
>>>     problem.
>>>      
>>>     Thanks,
>>>     David Holmes
>>>
>>>         -----Original Message-----
>>>         *From:* Martin Buchholz [mailto:martinrb at google.com
>>>         <mailto:martinrb at google.com>]
>>>         *Sent:* Tuesday, 14 July 2009 8:38 AM
>>>         *To:* Ariel Weisberg
>>>         *Cc:* davidcholmes at aapt.net.au
>>>         <mailto:davidcholmes at aapt.net.au>; core-libs-dev;
>>>         concurrency-interest at cs.oswego.edu
>>>         <mailto:concurrency-interest at cs.oswego.edu>
>>>         *Subject:* Re: [concurrency-interest] LinkedBlockingDeque
>>>         deadlock?
>>>
>>>         I did some stack trace eyeballing and did a mini-audit of the
>>>         LinkedBlockingDeque code, with a view to finding possible bugs,
>>>         and came up empty.  Maybe it's a deep bug in hotspot?
>>>
>>>         Ariel, it would be good if you could get a reproducible test
>>>         case soonish,
>>>         while someone on the planet has the motivation and
>>>         familiarity to fix it.
>>>         In another month I may disavow all knowledge of j.u.c.*Blocking*
>>>
>>>         Martin
>>>
>>>
>>>         On Wed, Jul 8, 2009 at 15:57, Ariel Weisberg
>>>         <ariel at weisberg.ws <mailto:ariel at weisberg.ws>> wrote:
>>>
>>>             Hi,
>>>
>>>             > The poll()ing thread is blocked waiting for the
>>>             internal lock, but
>>>             > there's
>>>             > no indication of any thread owning that lock. You're
>>>             using an OpenJDK 6
>>>             > build ... can you try JDK7 ?
>>>              
>>>             I got a chance to do that today. I downloaded JDK 7 from
>>>             http://www.java.net/download/jdk7/binaries/jdk-7-ea-bin-b63-linux-x64-02_jul_2009.bin
>>>             and was able to reproduce the problem. I have attached
>>>             the stack trace
>>>             from running the 1.7 version. It is the same situation as
>>>             before except
>>>             there are 9 execution sites running on each host. There
>>>             are no threads
>>>             that are missing or that have been restarted. Foo Network
>>>             thread
>>>             (selector thread) and Network Thread - 0 are waiting on
>>>             0x00002aaab43d3b28. I also ran with JDK 7 and 6 and
>>>             LinkedBlockingQueue
>>>             and was not able to recreate the problem using that
>>>             structure.
>>>
>>>             > I don't recall anything similar to this, but I don't
>>>             know what version
>>>             > that
>>>             > OpenJDK6 build relates to.
>>>              
>>>             The cluster is running on CentOS 5.3.
>>>             >[aweisberg at 3f ~]$ rpm -qi
>>>             java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5
>>>             >Name        : java-1.6.0-openjdk           Relocations:
>>>             (not relocatable)
>>>             >Version     : 1.6.0.0                           Vendor:
>>>             CentOS
>>>             >Release     : 0.30.b09.el5                  Build Date:
>>>             Tue 07 Apr 2009 07:24:52 PM EDT
>>>             >Install Date: Thu 11 Jun 2009 03:27:46 PM EDT      Build
>>>             Host: builder10.centos.org <http://builder10.centos.org>
>>>             >Group       : Development/Languages         Source RPM:
>>>             java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5.src.rpm
>>>             >Size        : 76336266                         License:
>>>             GPLv2 with exceptions
>>>             >Signature   : DSA/SHA1, Wed 08 Apr 2009 07:55:13 AM EDT,
>>>             Key ID a8a447dce8562897
>>>             >URL         : http://icedtea.classpath.org/
>>>             >Summary     : OpenJDK Runtime Environment
>>>             >Description :
>>>             >The OpenJDK runtime environment.
>>>
>>>             > Make sure you haven't missed any exceptions occurring
>>>             in other threads.
>>>             There are no threads missing in the application
>>>             (terminated threads are
>>>             not replaced) and there is a try catch pair (prints error
>>>             and rethrows)
>>>             around the run loop of each thread. It is possible that
>>>             an exception may
>>>             have been swallowed up somewhere.
>>>
>>>             >A small reproducible test case from you would be useful.
>>>             I am working on that. I wrote a test case that mimics the
>>>             application's
>>>             use of the LBD, but I have not succeeded in reproducing
>>>             the problem in
>>>             the test case. The app has a single thread (network
>>>             selector) that polls
>>>             the LBD and several threads (ExecutionSites, and network
>>>             threads that
>>>             return results from remote ExecutionSites) that offer
>>>             results into the
>>>             queue. About 120k items will go into/out of the deque
>>>             each second. In
>>>             the actual app the problem is reproducible but
>>>             inconsistent. If I run on
>>>             my dual core laptop I can't reproduce it, and it is less
>>>             likely to occur
>>>             with a small cluster, but with 6 nodes (~560k
>>>             transactions/sec) the
>>>             problem will usually appear. Sometimes the cluster will
>>>             run for several
>>>             minutes without issue and other times it will deadlock
>>>             immediately.
>>>
>>>             Thanks,
>>>
>>>             Ariel
>>>
>>>             On Wed, 08 Jul 2009 05:14 +1000, "Martin Buchholz"
>>>             <martinrb at google.com <mailto:martinrb at google.com>> wrote:
>>>             >[+core-libs-dev]
>>>             >
>>>             >Doug Lea and I are (slowly) working on a new version of
>>>             LinkedBlockingDeque.
>>>             >I was not aware of a deadlock but can vaguely imagine
>>>             how it might happen.
>>>             >A small reproducible test case from you would be useful.
>>>             >
>>>             >Unfinished work in progress can be found here:
>>>             >http://cr.openjdk.java.net/~martin/webrevs/openjdk7/BlockingQueue/
>>>             <http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/BlockingQueue/>
>>>             >
>>>             >Martin
>>>              
>>>             On Wed, 08 Jul 2009 05:14 +1000, "David Holmes"
>>>             <davidcholmes at aapt.net.au
>>>             <mailto:davidcholmes at aapt.net.au>> wrote:
>>>             >
>>>              
>>>             > Ariel,
>>>             >
>>>             > The poll()ing thread is blocked waiting for the
>>>             internal lock, but
>>>             > there's
>>>             > no indication of any thread owning that lock. You're
>>>             using an OpenJDK 6
>>>             > build ... can you try JDK7 ?
>>>             >
>>>             > I don't recall anything similar to this, but I don't
>>>             know what version
>>>             > that
>>>             > OpenJDK6 build relates to.
>>>             >
>>>             > Make sure you haven't missed any exceptions occurring
>>>             in other threads.
>>>             >
>>>             > David Holmes
>>>             >
>>>             > > -----Original Message-----
>>>             > > From: concurrency-interest-bounces at cs.oswego.edu
>>>             <mailto:concurrency-interest-bounces at cs.oswego.edu>
>>>             > > [mailto:concurrency-interest-bounces at cs.oswego.edu
>>>             <mailto:concurrency-interest-bounces at cs.oswego.edu>]On
>>>             Behalf Of Ariel
>>>             > > Weisberg
>>>             > > Sent: Wednesday, 8 July 2009 8:31 AM
>>>             > > To: concurrency-interest at cs.oswego.edu
>>>             <mailto:concurrency-interest at cs.oswego.edu>
>>>             > > Subject: [concurrency-interest] LinkedBlockingDeque
>>>             deadlock?
>>>             > >
>>>             > >
>>>             > > Hi all,
>>>             > >
>>>             > > I did a search on LinkedBlockingDeque and didn't find
>>>             anything similar
>>>             > > to what I am seeing. Attached is the stack trace from
>>>             an application
>>>             > > that is deadlocked with three threads waiting for
>>>             0x00002aaab3e91080
>>>             > > (threads "ExecutionSite: 26", "ExecutionSite:27", and
>>>             "Network
>>>             > > Selector"). The execution sites are attempting to
>>>             offer results to the
>>>             > > deque and the network thread is trying to poll for
>>>             them using the
>>>             > > non-blocking version of poll. I am seeing the network
>>>             thread never
>>>             > > return from poll (straight poll()). Do my eyes
>>>             deceive me?
>>>             > >
>>>             > > Thanks,
>>>             > >
>>>             > > Ariel Weisberg
>>>             > >
>>>             >
>>>
>>>
> 
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
> 


From Ulf.Zibis at gmx.de  Thu Jul 16 08:40:11 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 16 Jul 2009 10:40:11 +0200
Subject: Fwd: Reg : How to contribute
In-Reply-To: <17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>	<4A5DB724.50702@sun.com>	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>	<4A5DEA23.2090100@gmx.de>	<17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com>
	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
Message-ID: <4A5EE76B.1030508@gmx.de>

Am 15.07.2009 16:41, Andrew John Hughes schrieb:
>
> Err... webrev is available, several external contributors such as
> myself have already posted patches using it.
>   

Andrew,

can you tell me how you got access to the server as external contributor 
to post your patches?


Thanks,

-Ulf




From Ulf.Zibis at gmx.de  Thu Jul 16 08:46:22 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 16 Jul 2009 10:46:22 +0200
Subject: Reg : How to contribute
In-Reply-To: <4A5E2110.6030705@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
	<4A5DED16.2080407@gmx.de> <4A5DEDDC.8070106@sun.com>
	<4A5E04AF.2010302@gmx.de> <4A5E13B1.6080406@sun.com>
	<4A5E1984.3070004@gmx.de> <4A5E2110.6030705@sun.com>
Message-ID: <4A5EE8DE.6000600@gmx.de>

Am 15.07.2009 20:33, Lance J. Andersen schrieb:
>
>
> If you have push access to the  workspace, you should be able to  to 
> do this now.  

The magic word: "If ..."
My question is, how to get this "push access", maybe limited only for 
the webrev space.

> There is not tutorial outside of the blog that I know of but this 
> should get you started http://blogs.sun.com/jcc/date/20080211
>
> It is really pretty straightforward, it will create a directory with 
> the generated html files of your changes... I believe some versions 
> might create a zip for you of your webrev.

Much thanks, that link is really helpful.

-Ulf




From aph at redhat.com  Thu Jul 16 09:17:27 2009
From: aph at redhat.com (Andrew Haley)
Date: Thu, 16 Jul 2009 10:17:27 +0100
Subject: Fwd: Reg : How to contribute
In-Reply-To: <4A5EE76B.1030508@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>	<4A5DB724.50702@sun.com>	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>	<4A5DEA23.2090100@gmx.de>	<17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com>	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
	<4A5EE76B.1030508@gmx.de>
Message-ID: <4A5EF027.2050903@redhat.com>

Ulf Zibis wrote:
> Am 15.07.2009 16:41, Andrew John Hughes schrieb:
>>
>> Err... webrev is available, several external contributors such as
>> myself have already posted patches using it.
>>   
> 
> Andrew,
> 
> can you tell me how you got access to the server as external contributor
> to post your patches?

1.  Sign the SCA.

2.  Apply for commit access.

Andrew.


From Ulf.Zibis at gmx.de  Thu Jul 16 09:34:17 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 16 Jul 2009 11:34:17 +0200
Subject: Fwd: Reg : How to contribute
In-Reply-To: <4A5EF027.2050903@redhat.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>	<4A5DB724.50702@sun.com>	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>	<4A5DEA23.2090100@gmx.de>	<17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com>	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
	<4A5EE76B.1030508@gmx.de> <4A5EF027.2050903@redhat.com>
Message-ID: <4A5EF419.9090104@gmx.de>

Am 16.07.2009 11:17, Andrew Haley schrieb:
> Ulf Zibis wrote:
>   
>> Andrew,
>> can you tell me how you got access to the server as external contributor
>> to post your patches?
>>     
>
> 1.  Sign the SCA.
>   

Yep, done since long time.

> 2.  Apply for commit access.
>   

Where? Can you give me a link or name/email of responsible person?

Much thanks,

-Ulf




From aph at redhat.com  Thu Jul 16 09:37:19 2009
From: aph at redhat.com (Andrew Haley)
Date: Thu, 16 Jul 2009 10:37:19 +0100
Subject: Fwd: Reg : How to contribute
In-Reply-To: <4A5EF419.9090104@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>	<4A5DB724.50702@sun.com>	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>	<4A5DEA23.2090100@gmx.de>	<17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com>	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
	<4A5EE76B.1030508@gmx.de> <4A5EF027.2050903@redhat.com>
	<4A5EF419.9090104@gmx.de>
Message-ID: <4A5EF4CF.9050903@redhat.com>

Ulf Zibis wrote:
> Am 16.07.2009 11:17, Andrew Haley schrieb:
>> Ulf Zibis wrote:
>>  
>>> Andrew,
>>> can you tell me how you got access to the server as external contributor
>>> to post your patches?
>>>     
>>
>> 1.  Sign the SCA.
>>   
> 
> Yep, done since long time.
> 
>> 2.  Apply for commit access.
> 
> Where? Can you give me a link or name/email of responsible person?

Many people at Sun read this, and I'm hoping one of them will reply.

In the meantime, it's not as though you need access to cr to post webrevs.

Andrew.


From Ulf.Zibis at gmx.de  Thu Jul 16 10:04:37 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 16 Jul 2009 12:04:37 +0200
Subject: Fwd: Reg : How to contribute
In-Reply-To: <4A5EF4CF.9050903@redhat.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>	<4A5DB724.50702@sun.com>	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>	<4A5DEA23.2090100@gmx.de>	<17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com>	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
	<4A5EE76B.1030508@gmx.de> <4A5EF027.2050903@redhat.com>
	<4A5EF419.9090104@gmx.de> <4A5EF4CF.9050903@redhat.com>
Message-ID: <4A5EFB35.20305@gmx.de>

Am 16.07.2009 11:37, Andrew Haley schrieb:
> Ulf Zibis wrote:
>   
>> Am 16.07.2009 11:17, Andrew Haley schrieb:
>>     
>>> Ulf Zibis wrote:
>>>  
>>>       
>>>> Andrew,
>>>> can you tell me how you got access to the server as external contributor
>>>> to post your patches?
>>>>     
>>>>         
>>> 1.  Sign the SCA.
>>>   
>>>       
>> Yep, done since long time.
>>
>>     
>>> 2.  Apply for commit access.
>>>       
>> Where? Can you give me a link or name/email of responsible person?
>>     
>
> Many people at Sun read this, and I'm hoping one of them will reply.
>   

OK, let's wait for it.

> In the meantime, it's not as though you need access to cr to post webrevs.
>   

I have seen, that each user has separate folder on this server. Do you 
mean, that I can define a folder name by my login user name and then it 
will work without asking for a dedicated account? That would be fine. 
BTW, what's your folder name there?

... and much thanks for your detailed help.

-Ulf




From aph at redhat.com  Thu Jul 16 10:07:29 2009
From: aph at redhat.com (Andrew Haley)
Date: Thu, 16 Jul 2009 11:07:29 +0100
Subject: Fwd: Reg : How to contribute
In-Reply-To: <4A5EFB35.20305@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>	<4A5DB724.50702@sun.com>	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>	<4A5DEA23.2090100@gmx.de>	<17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com>	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
	<4A5EE76B.1030508@gmx.de> <4A5EF027.2050903@redhat.com>
	<4A5EF419.9090104@gmx.de> <4A5EF4CF.9050903@redhat.com>
	<4A5EFB35.20305@gmx.de>
Message-ID: <4A5EFBE1.1030808@redhat.com>

Ulf Zibis wrote:
> Am 16.07.2009 11:37, Andrew Haley schrieb:
>> Ulf Zibis wrote:
>>  
>>> Am 16.07.2009 11:17, Andrew Haley schrieb:
>>>    
>>>> Ulf Zibis wrote:
>>>>  
>>>>      
>>>>> Andrew,
>>>>> can you tell me how you got access to the server as external
>>>>> contributor
>>>>> to post your patches?
>>>>>             
>>>> 1.  Sign the SCA.
>>>>         
>>> Yep, done since long time.
>>>
>>>    
>>>> 2.  Apply for commit access.
>>>>       
>>> Where? Can you give me a link or name/email of responsible person?
>>>     
>>
>> Many people at Sun read this, and I'm hoping one of them will reply.
>>   
> 
> OK, let's wait for it.
> 
>> In the meantime, it's not as though you need access to cr to post
>> webrevs.
> 
> I have seen, that each user has separate folder on this server. Do you
> mean, that I can define a folder name by my login user name and then it
> will work without asking for a dedicated account?

No.  Generate a webrev, put it on your own HTTP server.  You don't need
access to cr.  Once you get cr access, you can copy the webrevs there.

Andrew.


From Ulf.Zibis at gmx.de  Thu Jul 16 10:19:33 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 16 Jul 2009 12:19:33 +0200
Subject: Fwd: Reg : How to contribute
In-Reply-To: <4A5EFBE1.1030808@redhat.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>	<4A5DB724.50702@sun.com>	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>	<4A5DEA23.2090100@gmx.de>	<17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com>	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
	<4A5EE76B.1030508@gmx.de> <4A5EF027.2050903@redhat.com>
	<4A5EF419.9090104@gmx.de> <4A5EF4CF.9050903@redhat.com>
	<4A5EFB35.20305@gmx.de> <4A5EFBE1.1030808@redhat.com>
Message-ID: <4A5EFEB5.1070205@gmx.de>

Am 16.07.2009 12:07, Andrew Haley schrieb:
>
> No.  Generate a webrev, put it on your own HTTP server.  You don't need
> access to cr.  Once you get cr access, you can copy the webrevs there.
>
>   

Ah, that's good idea. Thanks very much.


-Ulf




From Lance.Andersen at Sun.COM  Thu Jul 16 11:32:08 2009
From: Lance.Andersen at Sun.COM (Lance Andersen)
Date: Thu, 16 Jul 2009 07:32:08 -0400
Subject: Reg : How to contribute
In-Reply-To: <4A5EF4CF.9050903@redhat.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de>
	<17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com>
	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
	<4A5EE76B.1030508@gmx.de> <4A5EF027.2050903@redhat.com>
	<4A5EF419.9090104@gmx.de> <4A5EF4CF.9050903@redhat.com>
Message-ID: <07DDCA9B-D800-4B97-9E1B-DC2E713380EF@sun.com>


On Jul 16, 2009, at 5:37 AM, Andrew Haley wrote:

> Ulf Zibis wrote:
>> Am 16.07.2009 11:17, Andrew Haley schrieb:
>>> Ulf Zibis wrote:
>>>
>>>> Andrew,
>>>> can you tell me how you got access to the server as external  
>>>> contributor
>>>> to post your patches?
>>>>
>>>
>>> 1.  Sign the SCA.
>>>
>>
>> Yep, done since long time.
>>
>>> 2.  Apply for commit access.
>>
>> Where? Can you give me a link or name/email of responsible person?
>
> Many people at Sun read this, and I'm hoping one of them will reply.

You are asking a good question here and I did not find guidelines in  
the developer's guide for the process of adding new committers.   
Typically in most open source projects, such as at ASF,  a potential  
committer would  get nominated by an existing committer and a vote  
would take place to approve the new committer.   A potential committer  
would get nominated based on their body of work that was accepted into  
the project.

Perhaps this is something that might need to be added to the  
developer's guide (that is the process of becoming a committer)

-Lance




>
> In the meantime, it's not as though you need access to cr to post  
> webrevs.
>
> Andrew.



From fweimer at bfk.de  Thu Jul 16 12:01:48 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Thu, 16 Jul 2009 12:01:48 +0000
Subject: Obscure eclipse failures with OpenJDK 7
In-Reply-To: <87bpqbeker.fsf@mid.deneb.enyo.de> (Florian Weimer's message of
	"Sat\, 02 May 2009 14\:53\:00 +0200")
References: <87bpqbeker.fsf@mid.deneb.enyo.de>
Message-ID: <824otc7s5v.fsf@mid.bfk.de>

* Florian Weimer:

> I guess that this is an incompatibility between the system zlib (which
> is loaded by Eclipse) and OpenJDK's copy.  Both use the same symbols,
> and with ELF dynamic linking, it is a bit hard to predict which
> definition gets picked up.

Can't anybody else reproduce this problem?  Shouldn't it be addressed
in some way?

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From fweimer at bfk.de  Thu Jul 16 12:29:20 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Thu, 16 Jul 2009 12:29:20 +0000
Subject: Spec update for Class#getDeclaredMethods()
Message-ID: <82r5wg6cbj.fsf@mid.bfk.de>

I suggest to replace:

| The elements [methods] in the array returned are not sorted and are
| not in any particular order.

with:

| If the class is a compiled Java class, the elements in the array are
| sorted according to the order of declaration in the source code.
| Otherwise, the elements are not in any particular order.

There is a growing amount of code which relies on predictable method
order, so backwards compatibility concerns implicitly dictate the
ordering.  The proposed change makes this explicit.

The other reflection methods should be updated in a similar fashion.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From forax at univ-mlv.fr  Thu Jul 16 12:47:14 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 16 Jul 2009 14:47:14 +0200
Subject: Spec update for Class#getDeclaredMethods()
In-Reply-To: <82r5wg6cbj.fsf@mid.bfk.de>
References: <82r5wg6cbj.fsf@mid.bfk.de>
Message-ID: <4A5F2152.9000400@univ-mlv.fr>

Florian Weimer a ?crit :
> I suggest to replace:
>
> | The elements [methods] in the array returned are not sorted and are
> | not in any particular order.
>
> with:
>
> | If the class is a compiled Java class, the elements in the array are
> | sorted according to the order of declaration in the source code.
> | Otherwise, the elements are not in any particular order.
>
> There is a growing amount of code which relies on predictable method
> order, so backwards compatibility concerns implicitly dictate the
> ordering.  The proposed change makes this explicit.
>
> The other reflection methods should be updated in a similar fashion

This sentences was conscientiously added between 1.1 and 1.2
and I know a small VM that returns the method using the vtable ordering 
for getMethod.

Your suggestion implies that potentially all VM implementors should 
change some parts of their VM
data structures.
Doesn't seem realistic, isn't it.

R?mi


From Eamonn.McManus at Sun.COM  Thu Jul 16 13:07:14 2009
From: Eamonn.McManus at Sun.COM (Eamonn McManus)
Date: Thu, 16 Jul 2009 15:07:14 +0200
Subject: Spec update for Class#getDeclaredMethods()
In-Reply-To: <82r5wg6cbj.fsf@mid.bfk.de>
References: <82r5wg6cbj.fsf@mid.bfk.de>
Message-ID: <4A5F2602.1090404@sun.com>

An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/b8ae4b3c/attachment.html>

From fweimer at bfk.de  Thu Jul 16 13:22:48 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Thu, 16 Jul 2009 13:22:48 +0000
Subject: Spec update for Class#getDeclaredMethods()
In-Reply-To: <4A5F2602.1090404@sun.com> (Eamonn McManus's message of "Thu\,
	16 Jul 2009 15\:07\:14 +0200")
References: <82r5wg6cbj.fsf@mid.bfk.de> <4A5F2602.1090404@sun.com>
Message-ID: <82eisg69uf.fsf@mid.bfk.de>

* Eamonn McManus:

> The proposed change could be made, but it is not just a spec
> change. All JVMs that don't currently conform to the spec would need
> to change, as R?mi Forax notes, and that includes the JDK and its
> derivatives. I'm not a HotSpot expert but my guess is that there's
> some pretty sensitive code involved that the HotSpot team might be
> reluctant to go poking around in.

*hmpf* There's some code out there which relies on source code order
of members (it's not just Preon).  Hotspot appears close enough to
guaranteeing it that programmers make this assumption.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From Ulf.Zibis at gmx.de  Thu Jul 16 13:33:30 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Thu, 16 Jul 2009 15:33:30 +0200
Subject: How to contribute - webrev question
In-Reply-To: <4A5EFEB5.1070205@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>	<4A5DB724.50702@sun.com>	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>	<4A5DEA23.2090100@gmx.de>	<17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com>	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>	<4A5EE76B.1030508@gmx.de>
	<4A5EF027.2050903@redhat.com>	<4A5EF419.9090104@gmx.de>
	<4A5EF4CF.9050903@redhat.com>	<4A5EFB35.20305@gmx.de>
	<4A5EFBE1.1030808@redhat.com> <4A5EFEB5.1070205@gmx.de>
Message-ID: <4A5F2C2A.6040103@gmx.de>

Now I have installed the Microsoft "Windows Services for UNIX" and can 
run a Korn Shell:

Running the script, I get following output:
<======================================================
$ dir
 Datentr?ger in Laufwerk C: ist STANDARD
 Volumeseriennummer: 14AD-C64D

 Verzeichnis von C:\Projects\OpenJDK7\jdk

16.07.2009  13:41    <DIR>          .
16.07.2009  13:41    <DIR>          ..
15.07.2009  20:25    <DIR>          .hg
27.03.2009  19:35                35 .hgignore
06.07.2009  23:59             2.000 .hgtags
27.03.2009  19:35    <DIR>          .jcheck
27.03.2009  19:35             1.503 ASSEMBLY_EXCEPTION
07.06.2009  21:03    <DIR>          build
08.05.2009  15:10    <DIR>          dist
27.03.2009  19:35            19.241 LICENSE
16.06.2009  17:28    <DIR>          make
15.05.2009  21:48             1.629 README
27.03.2009  19:42    <DIR>          src
16.06.2009  17:28    <DIR>          test
27.03.2009  19:35           127.498 THIRD_PARTY_README
16.07.2009  13:39            77.693 webrev
16.07.2009  13:39            77.693 webrev.bat
16.07.2009  13:39            77.693 webrev.txt
               9 Datei(en)        384.985 Bytes
               9 Verzeichnis(se), 12.247.605.248 Bytes frei
$ ksh webrev
detect_scm: webrev[2158]: hg: not found
Unable to determine SCM type currently in use.
For teamware: webrev looks for $CODEMGR_WS either in
              the environment or in the file list.
For mercurial: webrev runs 'hg root'.
$
======================================================>

Can anybody give me an hint, what to do next, to make this run?

I have hg.exe in "C:\Programme\TortoiseHg"

How must I configure path etc. to make hg found?

Thanks in advance,

-Ulf




From forax at univ-mlv.fr  Thu Jul 16 13:38:10 2009
From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=)
Date: Thu, 16 Jul 2009 15:38:10 +0200
Subject: Spec update for Class#getDeclaredMethods()
In-Reply-To: <82eisg69uf.fsf@mid.bfk.de>
References: <82r5wg6cbj.fsf@mid.bfk.de> <4A5F2602.1090404@sun.com>
	<82eisg69uf.fsf@mid.bfk.de>
Message-ID: <4A5F2D42.1060504@univ-mlv.fr>

Florian Weimer a ?crit :
> * Eamonn McManus:
>
>   
>> The proposed change could be made, but it is not just a spec
>> change. All JVMs that don't currently conform to the spec would need
>> to change, as R?mi Forax notes, and that includes the JDK and its
>> derivatives. I'm not a HotSpot expert but my guess is that there's
>> some pretty sensitive code involved that the HotSpot team might be
>> reluctant to go poking around in.
>>     
>
> *hmpf* There's some code out there which relies on source code order
> of members (it's not just Preon).  Hotspot appears close enough to
> guaranteeing it that programmers make this assumption
The solution is to not rely on reflection and to parse the bytecode 
using by example ASM :
see http://asm.ow2.org/

R?mi




From Dalibor.Topic at Sun.COM  Thu Jul 16 13:52:07 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Thu, 16 Jul 2009 15:52:07 +0200
Subject: Spec update for Class#getDeclaredMethods()
In-Reply-To: <4A5F2152.9000400@univ-mlv.fr>
References: <82r5wg6cbj.fsf@mid.bfk.de> <4A5F2152.9000400@univ-mlv.fr>
Message-ID: <4A5F3087.2000803@sun.com>

R?mi Forax wrote:
> Florian Weimer a ?crit :
>> I suggest to replace:
>>
>> | The elements [methods] in the array returned are not sorted and are
>> | not in any particular order.
>>
>> with:
>>
>> | If the class is a compiled Java class, the elements in the array are
>> | sorted according to the order of declaration in the source code.
>> | Otherwise, the elements are not in any particular order.
>>
>> There is a growing amount of code which relies on predictable method
>> order, so backwards compatibility concerns implicitly dictate the
>> ordering.  The proposed change makes this explicit.
>>
>> The other reflection methods should be updated in a similar fashion
> 
> This sentences was conscientiously added between 1.1 and 1.2
> and I know a small VM that returns the method using the vtable ordering
> for getMethod.
> 
> Your suggestion implies that potentially all VM implementors should
> change some parts of their VM
> data structures.
> Doesn't seem realistic, isn't it.

Unless the order of method declarations in the source code must be
preserved in the class file (I don't think that's the case), I don't 
think it would really be possible for JVM implementors to do that due 
to the lack of the ability to determine at runtime from the class file 
alone the 'original' permutation of the elements that corresponds to 
the one in the source code in general.

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin H?ring




From Lance.Andersen at Sun.COM  Thu Jul 16 13:54:12 2009
From: Lance.Andersen at Sun.COM (Lance J. Andersen)
Date: Thu, 16 Jul 2009 09:54:12 -0400
Subject: How to contribute - webrev question
In-Reply-To: <4A5F2C2A.6040103@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de>
	<17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com>
	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
	<4A5EE76B.1030508@gmx.de> <4A5EF027.2050903@redhat.com>
	<4A5EF419.9090104@gmx.de> <4A5EF4CF.9050903@redhat.com>
	<4A5EFB35.20305@gmx.de> <4A5EFBE1.1030808@redhat.com>
	<4A5EFEB5.1070205@gmx.de> <4A5F2C2A.6040103@gmx.de>
Message-ID: <4A5F3104.8050308@sun.com>

You could try

webrev -m to force it to use hg

otherwise make sure that hg is accessible to your shell scripts which it 
appears not to be.  Have you set your PATH for your shell?

I do not have a windows environment to try this  on myself I am afraid :-(

Ulf Zibis wrote:
> Now I have installed the Microsoft "Windows Services for UNIX" and can 
> run a Korn Shell:
>
> Running the script, I get following output:
> <======================================================
> $ dir
> Datentr?ger in Laufwerk C: ist STANDARD
> Volumeseriennummer: 14AD-C64D
>
> Verzeichnis von C:\Projects\OpenJDK7\jdk
>
> 16.07.2009  13:41    <DIR>          .
> 16.07.2009  13:41    <DIR>          ..
> 15.07.2009  20:25    <DIR>          .hg
> 27.03.2009  19:35                35 .hgignore
> 06.07.2009  23:59             2.000 .hgtags
> 27.03.2009  19:35    <DIR>          .jcheck
> 27.03.2009  19:35             1.503 ASSEMBLY_EXCEPTION
> 07.06.2009  21:03    <DIR>          build
> 08.05.2009  15:10    <DIR>          dist
> 27.03.2009  19:35            19.241 LICENSE
> 16.06.2009  17:28    <DIR>          make
> 15.05.2009  21:48             1.629 README
> 27.03.2009  19:42    <DIR>          src
> 16.06.2009  17:28    <DIR>          test
> 27.03.2009  19:35           127.498 THIRD_PARTY_README
> 16.07.2009  13:39            77.693 webrev
> 16.07.2009  13:39            77.693 webrev.bat
> 16.07.2009  13:39            77.693 webrev.txt
>               9 Datei(en)        384.985 Bytes
>               9 Verzeichnis(se), 12.247.605.248 Bytes frei
> $ ksh webrev
> detect_scm: webrev[2158]: hg: not found
> Unable to determine SCM type currently in use.
> For teamware: webrev looks for $CODEMGR_WS either in
>              the environment or in the file list.
> For mercurial: webrev runs 'hg root'.
> $
> ======================================================>
>
> Can anybody give me an hint, what to do next, to make this run?
>
> I have hg.exe in "C:\Programme\TortoiseHg"
>
> How must I configure path etc. to make hg found?
>
> Thanks in advance,
>
> -Ulf
>
>


From gnu_andrew at member.fsf.org  Thu Jul 16 13:57:01 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 16 Jul 2009 14:57:01 +0100
Subject: How to contribute - webrev question
In-Reply-To: <4A5F2C2A.6040103@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>
	<4A5EE76B.1030508@gmx.de> <4A5EF027.2050903@redhat.com>
	<4A5EF419.9090104@gmx.de> <4A5EF4CF.9050903@redhat.com>
	<4A5EFB35.20305@gmx.de> <4A5EFBE1.1030808@redhat.com>
	<4A5EFEB5.1070205@gmx.de> <4A5F2C2A.6040103@gmx.de>
Message-ID: <17c6771e0907160657i2228c149i7c14b73f3e4a33a2@mail.gmail.com>

2009/7/16 Ulf Zibis <Ulf.Zibis at gmx.de>:
> Now I have installed the Microsoft "Windows Services for UNIX" and can run a
> Korn Shell:
>
> Running the script, I get following output:
> <======================================================
> $ dir
> Datentr?ger in Laufwerk C: ist STANDARD
> Volumeseriennummer: 14AD-C64D
>
> Verzeichnis von C:\Projects\OpenJDK7\jdk
>
> 16.07.2009 ?13:41 ? ?<DIR> ? ? ? ? ?.
> 16.07.2009 ?13:41 ? ?<DIR> ? ? ? ? ?..
> 15.07.2009 ?20:25 ? ?<DIR> ? ? ? ? ?.hg
> 27.03.2009 ?19:35 ? ? ? ? ? ? ? ?35 .hgignore
> 06.07.2009 ?23:59 ? ? ? ? ? ? 2.000 .hgtags
> 27.03.2009 ?19:35 ? ?<DIR> ? ? ? ? ?.jcheck
> 27.03.2009 ?19:35 ? ? ? ? ? ? 1.503 ASSEMBLY_EXCEPTION
> 07.06.2009 ?21:03 ? ?<DIR> ? ? ? ? ?build
> 08.05.2009 ?15:10 ? ?<DIR> ? ? ? ? ?dist
> 27.03.2009 ?19:35 ? ? ? ? ? ?19.241 LICENSE
> 16.06.2009 ?17:28 ? ?<DIR> ? ? ? ? ?make
> 15.05.2009 ?21:48 ? ? ? ? ? ? 1.629 README
> 27.03.2009 ?19:42 ? ?<DIR> ? ? ? ? ?src
> 16.06.2009 ?17:28 ? ?<DIR> ? ? ? ? ?test
> 27.03.2009 ?19:35 ? ? ? ? ? 127.498 THIRD_PARTY_README
> 16.07.2009 ?13:39 ? ? ? ? ? ?77.693 webrev
> 16.07.2009 ?13:39 ? ? ? ? ? ?77.693 webrev.bat
> 16.07.2009 ?13:39 ? ? ? ? ? ?77.693 webrev.txt
> ? ? ? ? ? ? ?9 Datei(en) ? ? ? ?384.985 Bytes
> ? ? ? ? ? ? ?9 Verzeichnis(se), 12.247.605.248 Bytes frei
> $ ksh webrev
> detect_scm: webrev[2158]: hg: not found
> Unable to determine SCM type currently in use.
> For teamware: webrev looks for $CODEMGR_WS either in
> ? ? ? ? ? ? the environment or in the file list.
> For mercurial: webrev runs 'hg root'.
> $
> ======================================================>
>
> Can anybody give me an hint, what to do next, to make this run?
>
> I have hg.exe in "C:\Programme\TortoiseHg"
>
> How must I configure path etc. to make hg found?
>
> Thanks in advance,
>
> -Ulf
>
>
>

I think configuring the PATH on Windows is a little outside the scope
of this mailing list and there are plenty of sources for such
information elsewhere.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From fweimer at bfk.de  Thu Jul 16 14:10:02 2009
From: fweimer at bfk.de (Florian Weimer)
Date: Thu, 16 Jul 2009 14:10:02 +0000
Subject: Spec update for Class#getDeclaredMethods()
In-Reply-To: <4A5F2D42.1060504@univ-mlv.fr> (=?iso-8859-1?Q?=22R=E9mi?=
	Forax"'s message of "Thu\, 16 Jul 2009 15\:38\:10 +0200")
References: <82r5wg6cbj.fsf@mid.bfk.de> <4A5F2602.1090404@sun.com>
	<82eisg69uf.fsf@mid.bfk.de> <4A5F2D42.1060504@univ-mlv.fr>
Message-ID: <827hy867np.fsf@mid.bfk.de>

* R?mi Forax:

> The solution is to not rely on reflection and to parse the bytecode
> using by example ASM :
> see http://asm.ow2.org/

I think you'd still need to sort based on line numbers, which requires
debugging information which is not always available.

The only reliable way I know is to use a JSR 269 compiler plugin.
Members are guaranteed to be in source order over there.  (But this
still suffers from poor IDE support, AFAICS.)

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99


From Joe.Darcy at Sun.COM  Thu Jul 16 16:38:44 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 16 Jul 2009 09:38:44 -0700
Subject: Spec update for Class#getDeclaredMethods()
In-Reply-To: <827hy867np.fsf@mid.bfk.de>
References: <82r5wg6cbj.fsf@mid.bfk.de> <4A5F2602.1090404@sun.com>
	<82eisg69uf.fsf@mid.bfk.de> <4A5F2D42.1060504@univ-mlv.fr>
	<827hy867np.fsf@mid.bfk.de>
Message-ID: <4A5F5794.4050405@sun.com>

Florian Weimer wrote:
> * R?mi Forax:
>
>   
>> The solution is to not rely on reflection and to parse the bytecode
>> using by example ASM :
>> see http://asm.ow2.org/
>>     
>
> I think you'd still need to sort based on line numbers, which requires
> debugging information which is not always available.
>
> The only reliable way I know is to use a JSR 269 compiler plugin.
> Members are guaranteed to be in source order over there.  (But this
> still suffers from poor IDE support, AFAICS.)
>   

The source ordering from JSR 269 is only guaranteed if the information 
is coming from a source file; from javax.lang.model.element.TypeElement:

"Each method of this interface that returns a list of elements will 
return them in the order that is natural for the underlying source of 
program information. For example, if the underlying source of 
information is Java source code, then the elements will be returned in 
source code order."
http://java.sun.com/javase/6/docs/api/javax/lang/model/element/TypeElement.html

If the information is coming from a class file, elements will be 
returned in the same order as they were in the class file.

Note that in the case of core reflection, which actually mostly present 
a JVM model of the world rather than a Java source model, there are more 
cases where non-source artifacts can crop up, including but not limited 
to implicit no-arg constructors and bridge methods.

-Joe


From Joe.Darcy at Sun.COM  Thu Jul 16 16:54:02 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 16 Jul 2009 09:54:02 -0700
Subject: Spec update for Class#getDeclaredMethods()
In-Reply-To: <4A5F2D42.1060504@univ-mlv.fr>
References: <82r5wg6cbj.fsf@mid.bfk.de> <4A5F2602.1090404@sun.com>
	<82eisg69uf.fsf@mid.bfk.de> <4A5F2D42.1060504@univ-mlv.fr>
Message-ID: <4A5F5B2A.4010201@sun.com>

R?mi Forax wrote:
> Florian Weimer a ?crit :
>> * Eamonn McManus:
>>
>>  
>>> The proposed change could be made, but it is not just a spec
>>> change. All JVMs that don't currently conform to the spec would need
>>> to change, as R?mi Forax notes, and that includes the JDK and its
>>> derivatives. I'm not a HotSpot expert but my guess is that there's
>>> some pretty sensitive code involved that the HotSpot team might be
>>> reluctant to go poking around in.
>>>     
>>
>> *hmpf* There's some code out there which relies on source code order
>> of members (it's not just Preon).  Hotspot appears close enough to
>> guaranteeing it that programmers make this assumption
> The solution is to not rely on reflection and to parse the bytecode 
> using by example ASM :
> see http://asm.ow2.org/
>
> R?mi
>
>

One can also impose an ordering on the program elements.  Due to a 
mis-design in the original apt API we had to write such a comparator in 
com.sun.mirror.util.SourceOrderDeclScanner:

http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/7e0056ded28c/src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java

-Joe


From Jean-Christophe.Collet at Sun.COM  Thu Jul 16 15:19:16 2009
From: Jean-Christophe.Collet at Sun.COM (Jean-Christophe Collet)
Date: Thu, 16 Jul 2009 17:19:16 +0200
Subject: Reg : How to contribute
In-Reply-To: <4A5E0FAB.8060607@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
	<4A5DED16.2080407@gmx.de>
	<4A5DEDDC.8070106@sun.com> <4A5E0FAB.8060607@sun.com>
Message-ID: <4A5F44F4.2000401@sun.com>

Sure.

I'm putting the final touches to a tool I call jHg
It's a simple mercurial front end and a webrev generator. All written in 
Java.
It has a GUI as well a command line interface.
With it you can easily:
 - browse through the history of any mercurial workspace and of any file 
in the workspace
 - search the history
 - view the details of any changeset or group of changesets
 - view the details of the current status
 - Commit, Push, Pull, Update or Revert changes.
 - Generate a webrev of any set of changes. Upload it to 
cr.openjdk.java.net and/or preview the webrev in the browser.

I've attached a couple of simple screenshots.
Right now the tool is being tested internally and I'm fixing the last 
kinks. Hopefully I'll make it available to the community very soon.

Frances Ho wrote:
>
> Jessie (Jean-Christophe) has been working on a Java version of
> webrev.  Jessie - can you share a bit of what it'll cover?
>
>
> -Frances
>
>
> On 07/15/09 07:55, Dalibor Topic wrote:
>> Ulf Zibis wrote:
>>> but what to do with this script to make it work for me?
>>
>> I'm not sure I understand the question correctly - webrev is a shell 
>> script
>> that uses ksh, so you could mark it as executable and run it using 
>> ksh, for
>> example.
>>
>> cheers,
>> dalibor topic

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jHg-ss1.png
Type: image/png
Size: 155121 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/c43b2b64/jHg-ss1.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jHg-ss2.png
Type: image/png
Size: 116383 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/c43b2b64/jHg-ss2.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jHg-ss3.png
Type: image/png
Size: 57744 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/c43b2b64/jHg-ss3.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jean-christophe_collet.vcf
Type: text/x-vcard
Size: 246 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/c43b2b64/jean-christophe_collet.vcf>

From neal at gafter.com  Thu Jul 16 18:20:59 2009
From: neal at gafter.com (Neal Gafter)
Date: Thu, 16 Jul 2009 11:20:59 -0700
Subject: Reg : How to contribute
In-Reply-To: <07DDCA9B-D800-4B97-9E1B-DC2E713380EF@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com> 
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com> 
	<4A5DEA23.2090100@gmx.de>
	<17c6771e0907150741p1c5102b0tdecb0b889d115748@mail.gmail.com> 
	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com> 
	<4A5EE76B.1030508@gmx.de> <4A5EF027.2050903@redhat.com>
	<4A5EF419.9090104@gmx.de> <4A5EF4CF.9050903@redhat.com>
	<07DDCA9B-D800-4B97-9E1B-DC2E713380EF@sun.com>
Message-ID: <15e8b9d20907161120o73c706fcu3de5b4a977971232@mail.gmail.com>

On Thu, Jul 16, 2009 at 4:32 AM, Lance Andersen <Lance.Andersen at sun.com>wrote:

>  You are asking a good question here and I did not find guidelines in the
> developer's guide for the process of adding new committers.  Typically in
> most open source projects, such as at ASF,  a potential committer would  get
> nominated by an existing committer and a vote would take place to approve
> the new committer.   A potential committer would get nominated based on
> their body of work that was accepted into the project.
>
> Perhaps this is something that might need to be added to the developer's
> guide (that is the process of becoming a committer)
>

For the openjdk projects, a committer is added by becoming a member of a *group
*(e.g. the Core Libraries group) and then joining the *project* (e.g. jdk7)
to which you want to contribute.  The interim guidelines for group
membership are documented here <http://openjdk.java.net/groups/>:

A Member is a Participant who has demonstrated a history of significant
contributions to a Group, has been granted Membership by that Group, and has
signed the SCA<http://sun.com/software/opensource/contributor_agreement.jsp>.
If a Group has the power to grant membership then the existing Members of
that Group may promote an individual to Member status by a three-vote
consensus (three yays, no nays) carried out over a seven-day period.

The normal way for non-commiters to demonstrate a history of significant
contributions is through repeated application of the process described here
<http://openjdk.java.net/contribute/>:

This process is intended for developers who already have the skills required
to work on the JDK but who do not yet have full authorship (*i.e.*,
committer) rights. It allows such developers to demonstrate their abilities
by submitting meaningful contributions in the form of patches and by pairing
them with *sponsors*, *i.e.*, existing authors who can offer advice, help
them become familiar with the JDK development process, and eventually push
their patches into the appropriate Mercurial repository. Over time it's
expected that skilled contributors will eventually earn full authorship
rights for themselves.

Cheers,
Neal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/364d1775/attachment.html>

From Lance.Andersen at Sun.COM  Thu Jul 16 20:59:16 2009
From: Lance.Andersen at Sun.COM (Lance J. Andersen)
Date: Thu, 16 Jul 2009 16:59:16 -0400
Subject: Reg : How to contribute
In-Reply-To: <4A5F44F4.2000401@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
	<4A5DED16.2080407@gmx.de>
	<4A5DEDDC.8070106@sun.com> <4A5E0FAB.8060607@sun.com>
	<4A5F44F4.2000401@sun.com>
Message-ID: <4A5F94A4.60501@sun.com>

Jessie,

This looks promising.  Are you looking also to have this as a plugin to 
Netbeans and Eclipse as that would make this even more useful?

Regards
lance

Jean-Christophe Collet wrote:
> Sure.
>
> I'm putting the final touches to a tool I call jHg
> It's a simple mercurial front end and a webrev generator. All written 
> in Java.
> It has a GUI as well a command line interface.
> With it you can easily:
> - browse through the history of any mercurial workspace and of any 
> file in the workspace
> - search the history
> - view the details of any changeset or group of changesets
> - view the details of the current status
> - Commit, Push, Pull, Update or Revert changes.
> - Generate a webrev of any set of changes. Upload it to 
> cr.openjdk.java.net and/or preview the webrev in the browser.
>
> I've attached a couple of simple screenshots.
> Right now the tool is being tested internally and I'm fixing the last 
> kinks. Hopefully I'll make it available to the community very soon.
>
> Frances Ho wrote:
>>
>> Jessie (Jean-Christophe) has been working on a Java version of
>> webrev.  Jessie - can you share a bit of what it'll cover?
>>
>>
>> -Frances
>>
>>
>> On 07/15/09 07:55, Dalibor Topic wrote:
>>> Ulf Zibis wrote:
>>>> but what to do with this script to make it work for me?
>>>
>>> I'm not sure I understand the question correctly - webrev is a shell 
>>> script
>>> that uses ksh, so you could mark it as executable and run it using 
>>> ksh, for
>>> example.
>>>
>>> cheers,
>>> dalibor topic
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/fbc5e0dd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 155121 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/fbc5e0dd/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 116383 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/fbc5e0dd/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 57744 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/fbc5e0dd/attachment-0002.png>

From Lance.Andersen at Sun.COM  Thu Jul 16 21:06:11 2009
From: Lance.Andersen at Sun.COM (Lance J. Andersen)
Date: Thu, 16 Jul 2009 17:06:11 -0400
Subject: Reg : How to contribute
In-Reply-To: <4A5F44F4.2000401@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
	<4A5DED16.2080407@gmx.de>
	<4A5DEDDC.8070106@sun.com> <4A5E0FAB.8060607@sun.com>
	<4A5F44F4.2000401@sun.com>
Message-ID: <4A5F9643.8070204@sun.com>

Jesse,

One other question.  Does this replace the webrev script or does jHg 
still invoke the webrev script?

-lance

Jean-Christophe Collet wrote:
> Sure.
>
> I'm putting the final touches to a tool I call jHg
> It's a simple mercurial front end and a webrev generator. All written 
> in Java.
> It has a GUI as well a command line interface.
> With it you can easily:
> - browse through the history of any mercurial workspace and of any 
> file in the workspace
> - search the history
> - view the details of any changeset or group of changesets
> - view the details of the current status
> - Commit, Push, Pull, Update or Revert changes.
> - Generate a webrev of any set of changes. Upload it to 
> cr.openjdk.java.net and/or preview the webrev in the browser.
>
> I've attached a couple of simple screenshots.
> Right now the tool is being tested internally and I'm fixing the last 
> kinks. Hopefully I'll make it available to the community very soon.
>
> Frances Ho wrote:
>>
>> Jessie (Jean-Christophe) has been working on a Java version of
>> webrev.  Jessie - can you share a bit of what it'll cover?
>>
>>
>> -Frances
>>
>>
>> On 07/15/09 07:55, Dalibor Topic wrote:
>>> Ulf Zibis wrote:
>>>> but what to do with this script to make it work for me?
>>>
>>> I'm not sure I understand the question correctly - webrev is a shell 
>>> script
>>> that uses ksh, so you could mark it as executable and run it using 
>>> ksh, for
>>> example.
>>>
>>> cheers,
>>> dalibor topic
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/d3acceff/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 155121 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/d3acceff/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 116383 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/d3acceff/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 57744 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/d3acceff/attachment-0002.png>

From Jean-Christophe.Collet at Sun.COM  Thu Jul 16 21:16:53 2009
From: Jean-Christophe.Collet at Sun.COM (Jean-Christophe Collet)
Date: Thu, 16 Jul 2009 23:16:53 +0200
Subject: Reg : How to contribute
In-Reply-To: <4A5F9643.8070204@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
	<4A5DED16.2080407@gmx.de>
	<4A5DEDDC.8070106@sun.com> <4A5E0FAB.8060607@sun.com>
	<4A5F44F4.2000401@sun.com> <4A5F9643.8070204@sun.com>
Message-ID: <4A5F98C5.1050905@sun.com>

Lance J. Andersen wrote:
> Jesse,
>
> One other question.  Does this replace the webrev script or does jHg 
> still invoke the webrev script?
>

This is a replacement. webrev, being a shell script, is very hard to 
maintain, extend and make work across various platforms.
So the main motivation behind jHg was to rewrite it in Java. I figured I 
might as well add a few bells an whistles to make it more useful.

Actually, I've split the project in two:
- jMercurial is a library of classes to manipulate a mercurial 
workspace. It relies on the 'hg' command to manipulate the workspace, 
but it is a fairly complete abstraction of all the components of a 
workspace (Changeset, Tag, Change, etc...).
- jHg uses jMercurial.

So far it has been tested on Solaris, Linux, Windows and Mac OS X.

> -lance
>
> Jean-Christophe Collet wrote:
>> Sure.
>>
>> I'm putting the final touches to a tool I call jHg
>> It's a simple mercurial front end and a webrev generator. All written 
>> in Java.
>> It has a GUI as well a command line interface.
>> With it you can easily:
>> - browse through the history of any mercurial workspace and of any 
>> file in the workspace
>> - search the history
>> - view the details of any changeset or group of changesets
>> - view the details of the current status
>> - Commit, Push, Pull, Update or Revert changes.
>> - Generate a webrev of any set of changes. Upload it to 
>> cr.openjdk.java.net and/or preview the webrev in the browser.
>>
>> I've attached a couple of simple screenshots.
>> Right now the tool is being tested internally and I'm fixing the last 
>> kinks. Hopefully I'll make it available to the community very soon.
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jean-christophe_collet.vcf
Type: text/x-vcard
Size: 246 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/1bc807e1/jean-christophe_collet.vcf>

From Jean-Christophe.Collet at Sun.COM  Thu Jul 16 21:19:23 2009
From: Jean-Christophe.Collet at Sun.COM (Jean-Christophe Collet)
Date: Thu, 16 Jul 2009 23:19:23 +0200
Subject: Reg : How to contribute
In-Reply-To: <4A5F94A4.60501@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
	<4A5DED16.2080407@gmx.de>
	<4A5DEDDC.8070106@sun.com> <4A5E0FAB.8060607@sun.com>
	<4A5F44F4.2000401@sun.com> <4A5F94A4.60501@sun.com>
Message-ID: <4A5F995B.1090003@sun.com>

Lance J. Andersen wrote:
> Jessie,
>
> This looks promising.  Are you looking also to have this as a plugin 
> to Netbeans and Eclipse as that would make this even more useful?

I've thought about it. But I wanted to have something as lightweight as 
possible AND I don't know anything about NetBeans or Eclipse plugins :-)

>
> Regards
> lance
>
> Jean-Christophe Collet wrote:
>> Sure.
>>
>> I'm putting the final touches to a tool I call jHg
>> It's a simple mercurial front end and a webrev generator. All written 
>> in Java.
>> It has a GUI as well a command line interface.
>> With it you can easily:
>> - browse through the history of any mercurial workspace and of any 
>> file in the workspace
>> - search the history
>> - view the details of any changeset or group of changesets
>> - view the details of the current status
>> - Commit, Push, Pull, Update or Revert changes.
>> - Generate a webrev of any set of changes. Upload it to 
>> cr.openjdk.java.net and/or preview the webrev in the browser.
>>
>> I've attached a couple of simple screenshots.
>> Right now the tool is being tested internally and I'm fixing the last 
>> kinks. Hopefully I'll make it available to the community very soon.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jean-christophe_collet.vcf
Type: text/x-vcard
Size: 246 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/611cd7e8/jean-christophe_collet.vcf>

From Lance.Andersen at Sun.COM  Thu Jul 16 21:23:38 2009
From: Lance.Andersen at Sun.COM (Lance J. Andersen)
Date: Thu, 16 Jul 2009 17:23:38 -0400
Subject: Reg : How to contribute
In-Reply-To: <4A5F995B.1090003@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5DB724.50702@sun.com>
	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>
	<4A5DEA23.2090100@gmx.de> <4A5DEB7B.6090500@sun.com>
	<4A5DED16.2080407@gmx.de>
	<4A5DEDDC.8070106@sun.com> <4A5E0FAB.8060607@sun.com>
	<4A5F44F4.2000401@sun.com> <4A5F94A4.60501@sun.com>
	<4A5F995B.1090003@sun.com>
Message-ID: <4A5F9A5A.1000302@sun.com>



Jean-Christophe Collet wrote:
> Lance J. Andersen wrote:
>> Jessie,
>>
>> This looks promising.  Are you looking also to have this as a plugin 
>> to Netbeans and Eclipse as that would make this even more useful?
>
> I've thought about it. But I wanted to have something as lightweight 
> as possible AND I don't know anything about NetBeans or Eclipse 
> plugins :-)


Thanks for the info in the previous email.  I thought the webrev was 
java based but figured i should sanity check to make sure you :-)

Having a plugin would be great, especially for Netbean with its support 
for Project Keani in the latest release.  I am sure this would be very 
popular.  I have only poked at netbeans plugins myself.  But that can be 
phase two of the project...

I look forward to giving your new tool a try.

Again thanks for the feedback.  It is a little late in your part of the 
world isn't it? :-)
>
>>
>> Regards
>> lance
>>
>> Jean-Christophe Collet wrote:
>>> Sure.
>>>
>>> I'm putting the final touches to a tool I call jHg
>>> It's a simple mercurial front end and a webrev generator. All 
>>> written in Java.
>>> It has a GUI as well a command line interface.
>>> With it you can easily:
>>> - browse through the history of any mercurial workspace and of any 
>>> file in the workspace
>>> - search the history
>>> - view the details of any changeset or group of changesets
>>> - view the details of the current status
>>> - Commit, Push, Pull, Update or Revert changes.
>>> - Generate a webrev of any set of changes. Upload it to 
>>> cr.openjdk.java.net and/or preview the webrev in the browser.
>>>
>>> I've attached a couple of simple screenshots.
>>> Right now the tool is being tested internally and I'm fixing the 
>>> last kinks. Hopefully I'll make it available to the community very 
>>> soon.
>


From Ulf.Zibis at gmx.de  Fri Jul 17 01:23:15 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 17 Jul 2009 03:23:15 +0200
Subject: How to contribute - webrev question
In-Reply-To: <17c6771e0907160657i2228c149i7c14b73f3e4a33a2@mail.gmail.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>	
	<17c6771e0907150741q48be2f47n88ee725cadf3c086@mail.gmail.com>	
	<4A5EE76B.1030508@gmx.de> <4A5EF027.2050903@redhat.com>	
	<4A5EF419.9090104@gmx.de> <4A5EF4CF.9050903@redhat.com>	
	<4A5EFB35.20305@gmx.de> <4A5EFBE1.1030808@redhat.com>	
	<4A5EFEB5.1070205@gmx.de> <4A5F2C2A.6040103@gmx.de>
	<17c6771e0907160657i2228c149i7c14b73f3e4a33a2@mail.gmail.com>
Message-ID: <4A5FD283.1040408@gmx.de>

Am 16.07.2009 15:57, Andrew John Hughes schrieb:
>
> I think configuring the PATH on Windows is a little outside the scope
> of this mailing list and there are plenty of sources for such
> information elsewhere.
>   

Maybe you are right.

But my question is not, how to set a path on Windows, it's how the 
webrev script interoperates with paths, defined on Windows.
I have set the path to to the 'hg.exe' on Windows, but webrev script 
doesn't find it.

I've also posted my question to the Microsoft "Windows Services for 
UNIX" forum, but I'm afraid, that people there don't know how to 
interpret webrev's error message.

So where to find people developing inside JDK under Windows 
(additionally having knowledge about webrev script)?

Sorry, being inconvenient here,

-Ulf




From Ulf.Zibis at gmx.de  Fri Jul 17 01:48:22 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 17 Jul 2009 03:48:22 +0200
Subject: Reg : How to contribute
In-Reply-To: <4A5F94A4.60501@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>	<4A5DB724.50702@sun.com>	<15e8b9d20907150726n78f159e6nbc53b5013980efc5@mail.gmail.com>	<4A5DEA23.2090100@gmx.de>
	<4A5DEB7B.6090500@sun.com>	<4A5DED16.2080407@gmx.de>	<4A5DEDDC.8070106@sun.com>
	<4A5E0FAB.8060607@sun.com>	<4A5F44F4.2000401@sun.com>
	<4A5F94A4.60501@sun.com>
Message-ID: <4A5FD866.7070907@gmx.de>

I accompany Lance. It seems, that I better wait for that tool, than 
trying to make webrev work under Windows.

-Ulf


Am 16.07.2009 22:59, Lance J. Andersen schrieb:
> Jessie,
>
> This looks promising.  Are you looking also to have this as a plugin 
> to Netbeans and Eclipse as that would make this even more useful?
>
> Regards
> lance
>
> Jean-Christophe Collet wrote:
>> Sure.
>>
>> I'm putting the final touches to a tool I call jHg
>> It's a simple mercurial front end and a webrev generator. All written 
>> in Java.
>> It has a GUI as well a command line interface.
>> With it you can easily:
>> - browse through the history of any mercurial workspace and of any 
>> file in the workspace
>> - search the history
>> - view the details of any changeset or group of changesets
>> - view the details of the current status
>> - Commit, Push, Pull, Update or Revert changes.
>> - Generate a webrev of any set of changes. Upload it to 
>> cr.openjdk.java.net and/or preview the webrev in the browser.
>>
>> I've attached a couple of simple screenshots.
>> Right now the tool is being tested internally and I'm fixing the last 
>> kinks. Hopefully I'll make it available to the community very soon.
>>
>> Frances Ho wrote:
>>>
>>> Jessie (Jean-Christophe) has been working on a Java version of
>>> webrev.  Jessie - can you share a bit of what it'll cover?
>>>
>>>
>>> -Frances
>>>
>>>
>>> On 07/15/09 07:55, Dalibor Topic wrote:
>>>> Ulf Zibis wrote:
>>>>> but what to do with this script to make it work for me?
>>>>
>>>> I'm not sure I understand the question correctly - webrev is a 
>>>> shell script
>>>> that uses ksh, so you could mark it as executable and run it using 
>>>> ksh, for
>>>> example.
>>>>
>>>> cheers,
>>>> dalibor topic
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>



From martinrb at google.com  Fri Jul 17 01:49:30 2009
From: martinrb at google.com (Martin Buchholz)
Date: Thu, 16 Jul 2009 18:49:30 -0700
Subject: How to contribute - webrev question
In-Reply-To: <4A5FD283.1040408@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5EF027.2050903@redhat.com> <4A5EF419.9090104@gmx.de>
	<4A5EF4CF.9050903@redhat.com> <4A5EFB35.20305@gmx.de>
	<4A5EFBE1.1030808@redhat.com> <4A5EFEB5.1070205@gmx.de>
	<4A5F2C2A.6040103@gmx.de>
	<17c6771e0907160657i2228c149i7c14b73f3e4a33a2@mail.gmail.com>
	<4A5FD283.1040408@gmx.de>
Message-ID: <1ccfd1c10907161849q205b9dbew6e67cd32dea7ce04@mail.gmail.com>

The webrev script was developed by Sun developers for use on Solaris.
Use on Windows is unsupported.
You are not likely to find much support on this mailing list for
doing jdk development on windows, and especially not using
Microsoft "Windows Services for UNIX".
Sun engineers use Cygwin or MKS for creating a Unixoid
environment on Windows (but's it's still painful).

Martin

On Thu, Jul 16, 2009 at 18:23, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

> Am 16.07.2009 15:57, Andrew John Hughes schrieb:
>
>>
>> I think configuring the PATH on Windows is a little outside the scope
>> of this mailing list and there are plenty of sources for such
>> information elsewhere.
>>
>>
>
> Maybe you are right.
>
> But my question is not, how to set a path on Windows, it's how the webrev
> script interoperates with paths, defined on Windows.
> I have set the path to to the 'hg.exe' on Windows, but webrev script
> doesn't find it.
>
> I've also posted my question to the Microsoft "Windows Services for UNIX"
> forum, but I'm afraid, that people there don't know how to interpret
> webrev's error message.
>
> So where to find people developing inside JDK under Windows (additionally
> having knowledge about webrev script)?
>
> Sorry, being inconvenient here,
>
> -Ulf
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090716/170f47f7/attachment.html>

From Ulf.Zibis at gmx.de  Fri Jul 17 02:13:36 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 17 Jul 2009 04:13:36 +0200
Subject: How to contribute - webrev question
In-Reply-To: <1ccfd1c10907161849q205b9dbew6e67cd32dea7ce04@mail.gmail.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>	
	<4A5EF027.2050903@redhat.com> <4A5EF419.9090104@gmx.de>	
	<4A5EF4CF.9050903@redhat.com> <4A5EFB35.20305@gmx.de>	
	<4A5EFBE1.1030808@redhat.com> <4A5EFEB5.1070205@gmx.de>	
	<4A5F2C2A.6040103@gmx.de>	
	<17c6771e0907160657i2228c149i7c14b73f3e4a33a2@mail.gmail.com>	
	<4A5FD283.1040408@gmx.de>
	<1ccfd1c10907161849q205b9dbew6e67cd32dea7ce04@mail.gmail.com>
Message-ID: <4A5FDE50.4080107@gmx.de>

Much thanks, Martin, to rub my eyes.

I'm successive with Cygwin to run awk scripts on Windows, but there is 
no library for ksh (Kern Shell) :-(
MKS should be part of "Windows Services for UNIX", see 
<http://de.wikipedia.org/wiki/Korn-Shell>:

Die /MKS Korn shell/ ist eine weitere kommerzielle ksh-Implementierung. 
Sie ist Bestandteil von Microsofts 
<http://de.wikipedia.org/wiki/Microsoft> Windows Services for UNIX 
<http://de.wikipedia.org/wiki/Microsoft_Windows_Services_for_UNIX> (SFU) 
sowie dem Subsystem f?r UNIX-basierte Anwendungen (SUA) der Windows 
Vista <http://de.wikipedia.org/wiki/Microsoft_Windows_Vista> Enterprise 
und Ultimate Editionen.

But maybe nobody has ever tried to run webrev under MKS.

-Ulf



Am 17.07.2009 03:49, Martin Buchholz schrieb:
> The webrev script was developed by Sun developers for use on Solaris.
> Use on Windows is unsupported.
> You are not likely to find much support on this mailing list for
> doing jdk development on windows, and especially not using
> Microsoft "Windows Services for UNIX".
> Sun engineers use Cygwin or MKS for creating a Unixoid
> environment on Windows (but's it's still painful).
>
> Martin
>
> On Thu, Jul 16, 2009 at 18:23, Ulf Zibis <Ulf.Zibis at gmx.de 
> <mailto:Ulf.Zibis at gmx.de>> wrote:
>
>     Am 16.07.2009 15:57, Andrew John Hughes schrieb:
>
>
>         I think configuring the PATH on Windows is a little outside
>         the scope
>         of this mailing list and there are plenty of sources for such
>         information elsewhere.
>          
>
>
>     Maybe you are right.
>
>     But my question is not, how to set a path on Windows, it's how the
>     webrev script interoperates with paths, defined on Windows.
>     I have set the path to to the 'hg.exe' on Windows, but webrev
>     script doesn't find it.
>
>     I've also posted my question to the Microsoft "Windows Services
>     for UNIX" forum, but I'm afraid, that people there don't know how
>     to interpret webrev's error message.
>
>     So where to find people developing inside JDK under Windows
>     (additionally having knowledge about webrev script)?
>
>     Sorry, being inconvenient here,
>
>     -Ulf
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090717/cd90c4b5/attachment.html>

From Dalibor.Topic at Sun.COM  Fri Jul 17 11:00:49 2009
From: Dalibor.Topic at Sun.COM (Dalibor Topic)
Date: Fri, 17 Jul 2009 13:00:49 +0200
Subject: How to contribute - webrev question
In-Reply-To: <4A5FDE50.4080107@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5EF027.2050903@redhat.com> <4A5EF419.9090104@gmx.de>
	<4A5EF4CF.9050903@redhat.com> <4A5EFB35.20305@gmx.de>
	<4A5EFBE1.1030808@redhat.com> <4A5EFEB5.1070205@gmx.de>
	<4A5F2C2A.6040103@gmx.de>
	<17c6771e0907160657i2228c149i7c14b73f3e4a33a2@mail.gmail.com>
	<4A5FD283.1040408@gmx.de>
	<1ccfd1c10907161849q205b9dbew6e67cd32dea7ce04@mail.gmail.com>
	<4A5FDE50.4080107@gmx.de>
Message-ID: <4A6059E1.3060409@sun.com>

Ulf Zibis wrote:
> Much thanks, Martin, to rub my eyes.
> 
> I'm successive with Cygwin to run awk scripts on Windows, but there is
> no library for ksh (Kern Shell) :-(

There is pdksh, fwiw: http://cygwin.com/packages/pdksh/pdksh-5.2.14-3
but it may or may not work. It may be worth a try, of course.

cheers,
dalibor topic
-- 
*******************************************************************
Dalibor Topic                   Tel: (+49 40) 23 646 738
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic at sun.com
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht M?nchen: HRB 161028
Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin H?ring




From Ulf.Zibis at gmx.de  Fri Jul 17 12:17:30 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 17 Jul 2009 14:17:30 +0200
Subject: How to contribute - webrev question
In-Reply-To: <4A6059E1.3060409@sun.com>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5EF027.2050903@redhat.com> <4A5EF419.9090104@gmx.de>
	<4A5EF4CF.9050903@redhat.com> <4A5EFB35.20305@gmx.de>
	<4A5EFBE1.1030808@redhat.com> <4A5EFEB5.1070205@gmx.de>
	<4A5F2C2A.6040103@gmx.de>
	<17c6771e0907160657i2228c149i7c14b73f3e4a33a2@mail.gmail.com>
	<4A5FD283.1040408@gmx.de>
	<1ccfd1c10907161849q205b9dbew6e67cd32dea7ce04@mail.gmail.com>
	<4A5FDE50.4080107@gmx.de> <4A6059E1.3060409@sun.com>
Message-ID: <4A606BDA.5090207@gmx.de>

Am 17.07.2009 13:00, Dalibor Topic schrieb:
> Ulf Zibis wrote:
>   
>> Much thanks, Martin, to rub my eyes.
>>
>> I'm successive with Cygwin to run awk scripts on Windows, but there is
>> no library for ksh (Kern Shell) :-(
>>     
>
> There is pdksh, fwiw: http://cygwin.com/packages/pdksh/pdksh-5.2.14-3
> but it may or may not work. It may be worth a try, of course.
>
>   

Oops, I've overseen this in the list, because it starts with a 'p'.
Much thanks Dalibor,

-Ulf




From Xueming.Shen at Sun.COM  Fri Jul 17 16:14:45 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Fri, 17 Jul 2009 09:14:45 -0700
Subject: codereview request: 6639443/
In-Reply-To: <1ccfd1c10907141315t32d3d6c1wc87a630f0642310@mail.gmail.com>
References: <4A57CB2C.50707@sun.com>
	<1ccfd1c10907101739i782a270p50f2a3d3383f39e3@mail.gmail.com>
	<1ccfd1c10907131339p562edb4ejdadebc439d223f5d@mail.gmail.com>
	<4A5CE18F.7030906@sun.com>
	<1ccfd1c10907141315t32d3d6c1wc87a630f0642310@mail.gmail.com>
Message-ID: <4A60A375.8060501@sun.com>

Martin Buchholz wrote:
>
>
> On Tue, Jul 14, 2009 at 12:50, Xueming Shen <Xueming.Shen at sun.com 
> <mailto:Xueming.Shen at sun.com>> wrote:
>
>
>     (2)
>
>     a)    return (int)(char) uc ==uc;
>
>       is nice:-) but I would go with the "more easy to read"
>
>       return uc < Surrogate.UCS4_MIN;
>
>       if it were my code. Is there a big performance gain by doing that?
>
>
> That's almost, but not exactly the same - uc might be negative.
> (I don't know whether that can ever happen, though)
>  
> My code is likely to be slightly faster than
>
> return uc < Surrogate.UCS4_MIN && uc >= 0;

While it might be slightly faster, the trick has the "dependency" on the 
size of "char". I still
remember the discussion of 32-bit char type when were planning 
supplementary support,
so everything is possible:-)

I don't think we are actually using the "generate()" anyway in our code 
(or least in the
latest version), maybe we can simply remove the piece.

I'm OK to putback the change asis though.

Sherman


>
>
>     b) The "buffer" version and the "array" version of generate() are
>     not synced.
>
>
> Yikes!  Good catch.  Fixed - webrev regenerated.
>  
> Thanks,
>
> Martin



From Ulf.Zibis at gmx.de  Fri Jul 17 17:01:39 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 17 Jul 2009 19:01:39 +0200
Subject: How to contribute - webrev question
In-Reply-To: <4A606BDA.5090207@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>	<4A5EF027.2050903@redhat.com>
	<4A5EF419.9090104@gmx.de>	<4A5EF4CF.9050903@redhat.com>
	<4A5EFB35.20305@gmx.de>	<4A5EFBE1.1030808@redhat.com>
	<4A5EFEB5.1070205@gmx.de>	<4A5F2C2A.6040103@gmx.de>	<17c6771e0907160657i2228c149i7c14b73f3e4a33a2@mail.gmail.com>	<4A5FD283.1040408@gmx.de>	<1ccfd1c10907161849q205b9dbew6e67cd32dea7ce04@mail.gmail.com>	<4A5FDE50.4080107@gmx.de>
	<4A6059E1.3060409@sun.com> <4A606BDA.5090207@gmx.de>
Message-ID: <4A60AE73.3080706@gmx.de>

Hi all,

I'm very happy to successful run webrev on Windows :-)
Much thanks you all.

Now I have some errors when trying to 'webrev' a single file 'README' 
from my workspace.
I'm afraid, I don't understand, how to define a 'filelist'.
So please give me additional hint.

Here is what I tried:

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

ich at Mobi ~
$ dir /cygdrive
c  d  e

ich at Mobi ~
$ cd /cygdrive/c/Projects/OpenJDK7/jdk

ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
$ dir
ASSEMBLY_EXCEPTION  README              build  make  test
LICENSE             THIRD_PARTY_README  dist   src   webrev

ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
$ /usr/local/bin/webrev -b -o ../webrev -u UlfZibis README
   SCM detected: mercurial
 File list from: README
      Workspace: c:/Projects/OpenJDK7/jdk
Compare against: C:/Projects/Repositories/OpenJDK7-tl_jdk/jdk
      Output to: /cygdrive/c/Projects/OpenJDK7/jdk/../webrev
   Output Files:
abort: cannot follow nonexistent file: "README:"
        README:
                *** Error: file not in parent or child
abort: cannot follow nonexistent file: "This"
        This
                *** Error: file not in parent or child
abort: cannot follow nonexistent file: "See"
        See
                *** Error: file not in parent or child
abort: cannot follow nonexistent file: "Simple"
        Simple
                *** Error: file not in parent or child
abort: cannot follow nonexistent file: "1."
        1.
                *** Error: file not in parent or child
mkdir: cannot create directory `c:/Projects/OpenJDK7/jdk/http:': No such 
file or
 directory
        http://java.sun.com/javase/downloads/index.jsp
                mkdir: cannot create directory 
`/cygdrive/c/Projects/OpenJDK7/jd
k/../webrev/http:': No such file or directory
/usr/local/bin/webrev[2873]: cd: 
c:/Projects/OpenJDK7/jdk/http:/java.sun.com/jav
ase/downloads - No such file or directory
mkdir: cannot create directory 
`/cygdrive/c/Projects/OpenJDK7/jdk/../webrev/raw_
files/old/http:': No such file or directory
mkdir: cannot create directory 
`/cygdrive/c/Projects/OpenJDK7/jdk/../webrev/raw_
files/new/http:': No such file or directory
*** Error: file not in parent or child
abort: cannot follow nonexistent file: "Set"
        Set
                *** Error: file not in parent or child
abort: cannot follow nonexistent file: "2."
        2.
                *** Error: file not in parent or child
abort: cannot follow nonexistent file: "You'll"
        You'll
                *** Error: file not in parent or child
abort: cannot follow nonexistent file: "bcel.jar"
        bcel.jar
                *** Error: file not in parent or child
abort: cannot follow nonexistent file: "jibx-bind.jar"
        jibx-bind.jar
                *** Error: file not in parent or child

 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
       
ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
$ /usr/local/bin/webrev -h
/usr/local/bin/webrev[2107]: -h: unknown option
Usage:  webrev [common-options]
        webrev [common-options] ( <file> | - )
        webrev [common-options] -w <wx file>
        webrev [common-options] -l [arguments to 'putback']

Options:
        -v: Print the version of this tool.
        -b: Do not ignore changes in the amount of white space.
        -c <CR#>: Include link to CR (aka bugid) in the main page.
        -i <filename>: Include <filename> in the index.html file.
        -o <outdir>: Output webrev to specified directory.
        -p <compare-against>: Use specified parent wkspc or basis for 
comparison

        -w <wxfile>: Use specified wx active file.
        -u <username>: Use that username instead of 'guessing' one.
        -m: Forces the use of Mercurial
        -t: Forces the use of Teamware

Mercurial only options:
        -r rev: Compare against a specified revision
        -N: Skip 'hg outgoing', use only 'hg status'
        -f: Use the forest extension

Environment:
        WDIR: Control the output directory.
        WEBREV_BUGURL: Control the URL prefix for bugids.
        WEBREV_SACURL: Control the URL prefix for ARC cases.

SCM Environment:
        Teamware: CODEMGR_WS: Workspace location.
        Teamware: CODEMGR_PARENT: Parent workspace location.

Contact: jean-christophe.collet at sun.com for issues and bug reports.


ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
$ /usr/local/bin/webrev -b -o ../webrev -u UlfZibis < README | - >
bash: syntax error near unexpected token `newline'

ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
$ /usr/local/bin/webrev -b -o ../webrev -u UlfZibis README | -
bash: -: command not found
   SCM detected: mercurial
 File list from: README

ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
$ /usr/local/bin/webrev -b -o ../webrev -u UlfZibis < <README> | - >
bash: syntax error near unexpected token `<'

ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
$ /usr/local/bin/webrev -b -o ../webrev -u UlfZibis < <README> | -
bash: syntax error near unexpected token `<'

ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
$ /usr/local/bin/webrev -b -o ../webrev -u UlfZibis < README | -
bash: -: command not found
   SCM detected: mercurial

ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
$ /usr/local/bin/webrev -b -o ../webrev -u UlfZibis < README
   SCM detected: mercurial
      Workspace: c:/Projects/OpenJDK7/jdk
Compare against: C:/Projects/Repositories/OpenJDK7-tl_jdk/jdk
      Output to: /cygdrive/c/Projects/OpenJDK7/jdk/../webrev
   Output Files:
        .hgtags
                 patch new
        README
                 patch new
        make/Makefile
                 patch new
        make/com/sun/Makefile
                 patch new
        make/common/Defs-linux.gmk
                 patch new
        make/common/Defs-solaris.gmk
                 patch new
        make/common/Defs-windows.gmk
                 patch new
$
 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Am 17.07.2009 14:17, Ulf Zibis schrieb:
> Am 17.07.2009 13:00, Dalibor Topic schrieb:
>> Ulf Zibis wrote:
>>  
>>> Much thanks, Martin, to rub my eyes.
>>>
>>> I'm successive with Cygwin to run awk scripts on Windows, but there is
>>> no library for ksh (Kern Shell) :-(
>>>     
>>
>> There is pdksh, fwiw: http://cygwin.com/packages/pdksh/pdksh-5.2.14-3
>> but it may or may not work. It may be worth a try, of course.
>>
>>   
>
> Oops, I've overseen this in the list, because it starts with a 'p'.
> Much thanks Dalibor,
>
> -Ulf
>
>
>



From rbetts at gmail.com  Fri Jul 17 16:48:16 2009
From: rbetts at gmail.com (Ryan Betts)
Date: Fri, 17 Jul 2009 12:48:16 -0400
Subject: [concurrency-interest] LinkedBlockingDeque deadlock? (Test case)
In-Reply-To: <1ccfd1c10907151424t2f835a29y80a10228e0bc66c0@mail.gmail.com>
References: <NFBBKALFDCPFIDBNKAPCAEJGICAA.davidcholmes@aapt.net.au>
	<1247540368.18990.1324916035@webmail.messagingengine.com>
	<1247685852.19957.1325194693@webmail.messagingengine.com>
	<1ccfd1c10907151424t2f835a29y80a10228e0bc66c0@mail.gmail.com>
Message-ID: <8F046E81-CBFA-4185-A2A9-5E00D54CAE71@gmail.com>

Hello all,

I've been working with Ariel on the j.u.c.LinkedBlockingDeque deadlock  
we observe. The attached test case reproduces the deadlock  
intermittently, usually requiring several minutes. The test simply  
prints periods until it deadlocks. Attempts to produce a simpler test  
case using only ReentrantLock or without an ExecutorService were  
unsuccessful.

I've attached jstack reports showing the deadlocked case and the dmesg  
output from one of the servers that reproduces the defect. To date,  
this deadlock only occurs on our 2 socket i7s.

We have not filed a defect with Sun for this issue. If that would be  
helpful (or necessary), we would of course happily oblige.

$ java -version
java version "1.6.0"
OpenJDK  Runtime Environment (build 1.6.0-b09)
OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)

$ uname -a
Linux host3e 2.6.18-128.1.16.el5 #1 SMP Tue Jun 30 06:07:26 EDT 2009  
x86_64 x86_64 x86_64 GNU/Linux

$ javac LBDLockPatternTest.java
$ java LBDLockPatternTest


Thank you,
*--Ryan.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmesg.txt
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090717/e80bd33c/dmesg.txt>
-------------- next part --------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: LBDLockPatternTest.java
Type: application/octet-stream
Size: 1703 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090717/e80bd33c/LBDLockPatternTest.java>
-------------- next part --------------



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: jstack-24297.txt
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090717/e80bd33c/jstack-24297.txt>
-------------- next part --------------



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: jstack-25168.txt
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090717/e80bd33c/jstack-25168.txt>
-------------- next part --------------







From davidcholmes at aapt.net.au  Sat Jul 18 02:14:59 2009
From: davidcholmes at aapt.net.au (David Holmes)
Date: Sat, 18 Jul 2009 12:14:59 +1000
Subject: [concurrency-interest] LinkedBlockingDeque deadlock? (Test case)
In-Reply-To: <8F046E81-CBFA-4185-A2A9-5E00D54CAE71@gmail.com>
Message-ID: <NFBBKALFDCPFIDBNKAPCIEKJICAA.davidcholmes@aapt.net.au>


Ryan,

Thanks very much for this.

When this "deadlocks" does top show whether the java process is actually
quiet or is it still consuming CPU? I notice that in the stack dump the main
thread is in the process of unlocking the lock that the other threads are
waiting upon and hence the system is not deadlocked - unless that main
thread is actually "stuck" somewhere. Can you take a series of stackdumps to
see if/how the main thread is executing?

Feel free to just send them to me rather than the mailing lists.

Thanks,
David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Ryan
> Betts
> Sent: Saturday, 18 July 2009 2:48 AM
> To: concurrency-interest at cs.oswego.edu
> Cc: core-libs-dev
> Subject: Re: [concurrency-interest] LinkedBlockingDeque deadlock? (Test
> case)
>
>
> Hello all,
>
> I've been working with Ariel on the j.u.c.LinkedBlockingDeque deadlock
> we observe. The attached test case reproduces the deadlock
> intermittently, usually requiring several minutes. The test simply
> prints periods until it deadlocks. Attempts to produce a simpler test
> case using only ReentrantLock or without an ExecutorService were
> unsuccessful.
>
> I've attached jstack reports showing the deadlocked case and the dmesg
> output from one of the servers that reproduces the defect. To date,
> this deadlock only occurs on our 2 socket i7s.
>
> We have not filed a defect with Sun for this issue. If that would be
> helpful (or necessary), we would of course happily oblige.
>
> $ java -version
> java version "1.6.0"
> OpenJDK  Runtime Environment (build 1.6.0-b09)
> OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)
>
> $ uname -a
> Linux host3e 2.6.18-128.1.16.el5 #1 SMP Tue Jun 30 06:07:26 EDT 2009
> x86_64 x86_64 x86_64 GNU/Linux
>
> $ javac LBDLockPatternTest.java
> $ java LBDLockPatternTest
>
>
> Thank you,
> *--Ryan.
>
>
>



From davidcholmes at aapt.net.au  Sat Jul 18 02:28:14 2009
From: davidcholmes at aapt.net.au (David Holmes)
Date: Sat, 18 Jul 2009 12:28:14 +1000
Subject: [concurrency-interest] LinkedBlockingDeque deadlock? (Test case)
In-Reply-To: <NFBBKALFDCPFIDBNKAPCIEKJICAA.davidcholmes@aapt.net.au>
Message-ID: <NFBBKALFDCPFIDBNKAPCOEKJICAA.davidcholmes@aapt.net.au>


Sorry Ryan, misread the stack trace. The main thread is interacting with the
executors LBQ not the application one.

I'll see if I can use this test to reproduce the issue on Monday.

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of David
> Holmes
> Sent: Saturday, 18 July 2009 12:15 PM
> To: Ryan Betts; concurrency-interest at cs.oswego.edu
> Cc: core-libs-dev
> Subject: Re: [concurrency-interest] LinkedBlockingDeque deadlock? (Test
> case)
>
>
>
>
> Ryan,
>
> Thanks very much for this.
>
> When this "deadlocks" does top show whether the java process is actually
> quiet or is it still consuming CPU? I notice that in the stack
> dump the main
> thread is in the process of unlocking the lock that the other threads are
> waiting upon and hence the system is not deadlocked - unless that main
> thread is actually "stuck" somewhere. Can you take a series of
> stackdumps to
> see if/how the main thread is executing?
>
> Feel free to just send them to me rather than the mailing lists.
>
> Thanks,
> David Holmes
>
> > -----Original Message-----
> > From: concurrency-interest-bounces at cs.oswego.edu
> > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Ryan
> > Betts
> > Sent: Saturday, 18 July 2009 2:48 AM
> > To: concurrency-interest at cs.oswego.edu
> > Cc: core-libs-dev
> > Subject: Re: [concurrency-interest] LinkedBlockingDeque deadlock? (Test
> > case)
> >
> >
> > Hello all,
> >
> > I've been working with Ariel on the j.u.c.LinkedBlockingDeque deadlock
> > we observe. The attached test case reproduces the deadlock
> > intermittently, usually requiring several minutes. The test simply
> > prints periods until it deadlocks. Attempts to produce a simpler test
> > case using only ReentrantLock or without an ExecutorService were
> > unsuccessful.
> >
> > I've attached jstack reports showing the deadlocked case and the dmesg
> > output from one of the servers that reproduces the defect. To date,
> > this deadlock only occurs on our 2 socket i7s.
> >
> > We have not filed a defect with Sun for this issue. If that would be
> > helpful (or necessary), we would of course happily oblige.
> >
> > $ java -version
> > java version "1.6.0"
> > OpenJDK  Runtime Environment (build 1.6.0-b09)
> > OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)
> >
> > $ uname -a
> > Linux host3e 2.6.18-128.1.16.el5 #1 SMP Tue Jun 30 06:07:26 EDT 2009
> > x86_64 x86_64 x86_64 GNU/Linux
> >
> > $ javac LBDLockPatternTest.java
> > $ java LBDLockPatternTest
> >
> >
> > Thank you,
> > *--Ryan.
> >
> >
> >
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



From Ulf.Zibis at gmx.de  Sun Jul 19 09:05:44 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 19 Jul 2009 11:05:44 +0200
Subject: jdk7/tl/jdk - 5 integrity errors encountered
Message-ID: <4A62E1E8.7030306@gmx.de>

Hi all,

on my local clone of jdk7/tl/jdk repository I have run verify from 
TortoiesHG, and found 5 integrity errors encountered.

Maybe it's worth to do this check on your server too.

-Ulf


jdk7/tl/jdk - 5 integrity errors encountered

Text format for copy-n-paste facility:

repository uses revlog format 1
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
***  data/src/share/demo/jvmti/hprof/hprof_io.c.i at 0: missing revlog!
***  0: empty or missing src/share/demo/jvmti/hprof/hprof_io.c
***  src/share/demo/jvmti/hprof/hprof_io.c at 0: 1549d3b31663 in manifests 
not found
***  src/share/demo/jvmti/hprof/hprof_io.c at 422: df35d5bb75da in 
manifests not found
***  src/share/demo/jvmti/hprof/hprof_io.c at 603: 96041274c849 in 
manifests not found
18895 files, 1367 changesets, 25870 total revisions
*** 5 integrity errors encountered!
*** (first damaged changeset appears to be 0)
[command returned code 1]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090719/71048a55/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenJDK - 5 integrity errors encountered.png
Type: image/png
Size: 19510 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090719/71048a55/OpenJDK-5integrityerrorsencountered.png>

From Ulf.Zibis at gmx.de  Sun Jul 19 12:36:05 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 19 Jul 2009 14:36:05 +0200
Subject: My first webrev review request: 6850337 Hasher.java interprets given
	option value badly
Message-ID: <4A631335.4080400@gmx.de>

Martin, Sherman, Neal,

do you like to sponsor and review my CR ?

Don't worry, it's very simple and small, best for getting familiar with 
the workflow.

See:
https://bugs.openjdk.java.net/show_bug.cgi?id=100090

Thanks,

Ulf





From Ulf.Zibis at gmx.de  Sun Jul 19 12:47:14 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 19 Jul 2009 14:47:14 +0200
Subject: My first webrev review request: 6850337 Hasher.java interprets given
	option value badly
Message-ID: <4A6315D2.5070808@gmx.de>

Martin, Sherman, Neal, Dalibor,

do you like to review and/or sponsor my CR ?

Don't worry, it's very simple and small, best for getting familiar with
the workflow.

See:
https://bugs.openjdk.java.net/show_bug.cgi?id=100090

Thanks,

Ulf






From Ulf.Zibis at gmx.de  Sun Jul 19 15:56:21 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 19 Jul 2009 17:56:21 +0200
Subject: Review/sponsor request: 6795536 No system start for
	file.encoding=x-SJIS_0213
Message-ID: <4A634225.1080600@gmx.de>

Martin, Sherman, Neal, Dalibor,

do you like to review and/or sponsor my CR ?

Maybe this fix would become obsolete, if charset would be re-designed, but for future enhancements, 
I have in stack, this fix is mandatory.

Anyway, I don't this change would harm anything, as I've seen in the sources of JDK1.6.0_14, that 
similar changes have been made to java.lang.System.java there.

See:
https://bugs.openjdk.java.net/show_bug.cgi?id=100091

Thanks,

Ulf







From neal at gafter.com  Sun Jul 19 17:19:36 2009
From: neal at gafter.com (Neal Gafter)
Date: Sun, 19 Jul 2009 10:19:36 -0700
Subject: My first webrev review request: 6850337 Hasher.java interprets 
	given option value badly
In-Reply-To: <4A6315D2.5070808@gmx.de>
References: <4A6315D2.5070808@gmx.de>
Message-ID: <15e8b9d20907191019k46f6daf0xd350e196cf24d25c@mail.gmail.com>

I'm completely unfamiliar with Hasher.java.  I more frequently work on
sources in the langtools area.

On Sun, Jul 19, 2009 at 5:47 AM, Ulf Zibis <Ulf.Zibis at gmx.de> wrote:

> Martin, Sherman, Neal, Dalibor,
>
> do you like to review and/or sponsor my CR ?
>
>
> Don't worry, it's very simple and small, best for getting familiar with
> the workflow.
>
> See:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100090
>
> Thanks,
>
> Ulf
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090719/b3f68464/attachment.html>

From Ulf.Zibis at gmx.de  Sun Jul 19 17:49:41 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 19 Jul 2009 19:49:41 +0200
Subject: codereview request: 6639443/
In-Reply-To: <4A5CFBCA.60206@sun.com>
References: <4A57CB2C.50707@sun.com>
	<1ccfd1c10907101739i782a270p50f2a3d3383f39e3@mail.gmail.com>
	<1ccfd1c10907131339p562edb4ejdadebc439d223f5d@mail.gmail.com>
	<4A5CE18F.7030906@sun.com> <4A5CF21E.20505@gmx.de>
	<1ccfd1c10907141436w176ed97byb1146dd06fd2f99@mail.gmail.com>
	<4A5CFBCA.60206@sun.com>
Message-ID: <4A635CB5.7080006@gmx.de>

Sherman,

another 2 cents:

Please note, that 6798511 is more than duplicate of 6860431.
6860431 only cares about method isSurrogate().

-Ulf


Am 14.07.2009 23:42, Xueming Shen schrieb:
> Ulf,
>
> Usually I should close the newly filed bug 6860431 as the dup of 
> yours. But I have already
> used 6860431 as the bugid for the "internal" CCC filing, I closed 
> yours as the dup of 6860431
> to avoid filing the CCC again. Hope you don't mind.
>
> Sherman
>
> Martin Buchholz wrote:
>> Sorry, Ulf.
>>
>> The bug duplication might have been avoided
>> if the bug database was more searchable.
>> I need a command named .... jbugs ...
>>
>> Martin
>>
>> On Tue, Jul 14, 2009 at 14:01, Ulf Zibis <Ulf.Zibis at gmx.de 
>> <mailto:Ulf.Zibis at gmx.de>> wrote:
>>
>>     Am 14.07.2009 21:50, Xueming Shen schrieb:
>>
>>         I included the core-libs-dev as you suggested.
>>
>>         (3)6860431: Character.isSurrogate(char ch)
>>
>>         has been filed on your behalf, as well as the CCC
>>         http://ccc.sfbay.sun.com/6860431.
>>         Masayoshi, would you please review the spec and add yourself
>>         as the reviewer? I
>>         need the reviewer to fast-track it.
>>
>>
>>     Hehe, I was first:
>>     http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6798511
>>
>>     ;-)
>>
>>     -Ulf
>>
>>
>>
>
>



From Ulf.Zibis at gmx.de  Sun Jul 19 19:22:59 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Sun, 19 Jul 2009 21:22:59 +0200
Subject: Review/sponsor request: 6790402 Speed-up FastCharsetProvider
Message-ID: <4A637293.9060600@gmx.de>

Martin, Sherman, Neal, Dalibor,

do you like to review and/or sponsor my CR ?

This fix is more advanced. Hopefully I've not overseen important details.

See:
https://bugs.openjdk.java.net/show_bug.cgi?id=100092

Thanks,

Ulf








From gnu_andrew at member.fsf.org  Mon Jul 20 00:25:33 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Mon, 20 Jul 2009 01:25:33 +0100
Subject: My first webrev review request: 6850337 Hasher.java interprets 
	given option value badly
In-Reply-To: <4A631335.4080400@gmx.de>
References: <4A631335.4080400@gmx.de>
Message-ID: <17c6771e0907191725v3d818580idf94b905d9def198@mail.gmail.com>

2009/7/19 Ulf Zibis <Ulf.Zibis at gmx.de>:
> Martin, Sherman, Neal,
>
> do you like to sponsor and review my CR ?
>
> Don't worry, it's very simple and small, best for getting familiar with the
> workflow.
>
> See:
> https://bugs.openjdk.java.net/show_bug.cgi?id=100090
>
> Thanks,
>
> Ulf
>
>
>
>

As this bug is about a tool used during the build, your mail probably
wants to be directed to the build list.

Are you sure this is not done by design and that mb is not in fact
meant to be an exclusive rather than inclusive bound?

Have you checked that the OpenJDK can still be built with this change in place?

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From tim.bell at sun.com  Mon Jul 20 07:54:47 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 20 Jul 2009 07:54:47 +0000
Subject: hg: jdk7/tl: 16 new changesets
Message-ID: <20090720075448.19F06E812@hg.openjdk.java.net>

Changeset: c50469cf63cd
Author:    herrick
Date:      2009-06-11 15:15 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/c50469cf63cd

6797688: Umbrella: Merge all JDK 6u4 - 6u12 deployment code into JDK7
6845973: Update JDK7 with deployment changes in 6u13, 6u14
4802695: Support 64-bit Java Plug-in and Java webstart on Windows/Linux on AMD64
6825019: DownloadManager should not be loaded and referenced for full JRE
6738770: REGRESSION:JSException throws when use LiveConnect javascript facility
6772884: plugin2 : java.lang.OutOfMemoryError or crash
6707535: Crossing domain hole affecting multiple sites/domains using plug-in
6728071: Non-verification of Update files may allow unintended updates
6704154: Code loaded from local filesystem should not get access to localhost
6727081: Web Start security restrictions bypass using special extension jnlp
6727079: Java Web Start Socket() restriction bypass
6727071: Cache location/user name information disclosure in SingleInstanceImpl.
6716217: AppletClassLoader adds permissions based on codebase regardless of CS
6694892: Java Webstart inclusion via system properties override [CVE-2008-2086]
6704074: localhost socket access due to cache location exposed
6703909: Java webstart arbitrary file creation using nativelib
6665315: browser crashes when deployment.properties has more slashes ( / )
6660121: Encoding values in JNLP files can cause buffer overflow
6606110: URLConnection.setProxiedHost for resources that are loaded via proxy
6581221: SSV(VISTA): Redirection FAILS to work if user does a downgrade install
6609756: Buffer Overflow in Java ActiveX component
6608712: Bypassing the same origin policy in Java with crafted names
6534630: "gnumake clobber" doesn't
6849953: JDK7 - replacement of bufferoverflowU.lib on amd64 breaks build
6849029: Need some JDK7 merge clean-up after comments on the webrev
6847582: Build problem on JDK7 with isSecureProperty in merge
6827935: JDK 7 deployment merging - problem in Compiler-msvm.gmk
6823215: latest merge fixes from 6u12 -> JDK7
6816153: further mergers for JDK7 deployment integration
6807074: Fix Java Kernel and JQS in initial JDK7 builds
Summary: Initial changeset for implementing 6uX Deployment Features into JDK7
Reviewed-by: dgu, billyh

! make/deploy-rules.gmk

Changeset: c7c4850f1478
Author:    herrick
Date:      2009-06-15 13:07 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/c7c4850f1478

Merge


Changeset: d28a8c422df1
Author:    herrick
Date:      2009-06-22 09:14 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/d28a8c422df1

Merge


Changeset: 528e4cc7541b
Author:    herrick
Date:      2009-06-29 12:00 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/528e4cc7541b

Merge


Changeset: 9f4fc871bf4d
Author:    herrick
Date:      2009-07-06 15:02 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/9f4fc871bf4d

Merge


Changeset: 03119516abbc
Author:    herrick
Date:      2009-07-06 14:01 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/03119516abbc

Merge


Changeset: 633840bd4c5b
Author:    jqzuo
Date:      2009-07-07 10:14 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/633840bd4c5b

Merge


Changeset: 46c0f8989eb2
Author:    herrick
Date:      2009-07-06 17:12 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/46c0f8989eb2

Merge


Changeset: 3e781aa606d4
Author:    ohair
Date:      2009-07-06 22:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/3e781aa606d4

6857805: Fix openjdk builds to avoid building deploy repository
Reviewed-by: xdono

! make/Defs-internal.gmk
! make/deploy-rules.gmk

Changeset: 269c1ec4435d
Author:    jqzuo
Date:      2009-07-07 10:20 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/269c1ec4435d

Merge


Changeset: d92b13b3c138
Author:    xdono
Date:      2009-07-13 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/d92b13b3c138

Added tag jdk7-b64 for changeset 269c1ec4435d

! .hgtags

Changeset: 8ca3d95b1ea3
Author:    xdono
Date:      2009-06-22 10:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/8ca3d95b1ea3

6853596: Update Build README-build.html with new info regarding update for Solaris 10u2 and BOOTDIR update
Reviewed-by: tbell, ohair

! README-builds.html

Changeset: 38c6ee1015aa
Author:    xdono
Date:      2009-06-29 22:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/38c6ee1015aa

Merge

! README-builds.html

Changeset: 9ed059501673
Author:    xdono
Date:      2009-07-08 10:34 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/9ed059501673

Merge


Changeset: e01380cd1de4
Author:    xdono
Date:      2009-07-14 14:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/e01380cd1de4

Merge


Changeset: 6bad5e3fe503
Author:    xdono
Date:      2009-07-16 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/6bad5e3fe503

Added tag jdk7-b65 for changeset e01380cd1de4

! .hgtags



From tim.bell at sun.com  Mon Jul 20 08:00:07 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 20 Jul 2009 08:00:07 +0000
Subject: hg: jdk7/tl/corba: 9 new changesets
Message-ID: <20090720080015.99B16E817@hg.openjdk.java.net>

Changeset: ffb590b42ed1
Author:    herrick
Date:      2009-06-11 15:16 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/ffb590b42ed1

6797688: Umbrella: Merge all JDK 6u4 - 6u12 deployment code into JDK7
6845973: Update JDK7 with deployment changes in 6u13, 6u14
4802695: Support 64-bit Java Plug-in and Java webstart on Windows/Linux on AMD64
6825019: DownloadManager should not be loaded and referenced for full JRE
6738770: REGRESSION:JSException throws when use LiveConnect javascript facility
6772884: plugin2 : java.lang.OutOfMemoryError or crash
6707535: Crossing domain hole affecting multiple sites/domains using plug-in
6728071: Non-verification of Update files may allow unintended updates
6704154: Code loaded from local filesystem should not get access to localhost
6727081: Web Start security restrictions bypass using special extension jnlp
6727079: Java Web Start Socket() restriction bypass
6727071: Cache location/user name information disclosure in SingleInstanceImpl.
6716217: AppletClassLoader adds permissions based on codebase regardless of CS
6694892: Java Webstart inclusion via system properties override [CVE-2008-2086]
6704074: localhost socket access due to cache location exposed
6703909: Java webstart arbitrary file creation using nativelib
6665315: browser crashes when deployment.properties has more slashes ( / )
6660121: Encoding values in JNLP files can cause buffer overflow
6606110: URLConnection.setProxiedHost for resources that are loaded via proxy
6581221: SSV(VISTA): Redirection FAILS to work if user does a downgrade install
6609756: Buffer Overflow in Java ActiveX component
6608712: Bypassing the same origin policy in Java with crafted names
6534630: "gnumake clobber" doesn't
6849953: JDK7 - replacement of bufferoverflowU.lib on amd64 breaks build
6849029: Need some JDK7 merge clean-up after comments on the webrev
6847582: Build problem on JDK7 with isSecureProperty in merge
6827935: JDK 7 deployment merging - problem in Compiler-msvm.gmk
6823215: latest merge fixes from 6u12 -> JDK7
6816153: further mergers for JDK7 deployment integration
6807074: Fix Java Kernel and JQS in initial JDK7 builds
Summary: Initial changeset for implementing 6uX Deployment Features into JDK7
Reviewed-by: dgu, billyh

! make/common/Defs-windows.gmk
! make/common/Library.gmk
! make/org/omg/idl/Makefile
! src/windows/resource/version.rc

Changeset: 79d8fd9e74b9
Author:    herrick
Date:      2009-06-15 13:07 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/79d8fd9e74b9

Merge

- make/README

Changeset: 1b3e9fdc4fc5
Author:    herrick
Date:      2009-06-22 09:14 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/1b3e9fdc4fc5

Merge


Changeset: 27f41fcf3d6a
Author:    herrick
Date:      2009-06-29 12:00 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/27f41fcf3d6a

Merge


Changeset: f982791bb7d4
Author:    herrick
Date:      2009-07-06 15:04 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/f982791bb7d4

Merge


Changeset: 863559dbbced
Author:    herrick
Date:      2009-07-06 14:02 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/863559dbbced

Merge


Changeset: 047dd27fddb6
Author:    herrick
Date:      2009-07-06 17:11 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/047dd27fddb6

Merge


Changeset: 97fd9b42f5c2
Author:    xdono
Date:      2009-07-13 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/97fd9b42f5c2

Added tag jdk7-b64 for changeset 047dd27fddb6

! .hgtags

Changeset: a821e059a961
Author:    xdono
Date:      2009-07-16 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/a821e059a961

Added tag jdk7-b65 for changeset 97fd9b42f5c2

! .hgtags



From tim.bell at sun.com  Mon Jul 20 08:08:54 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 20 Jul 2009 08:08:54 +0000
Subject: hg: jdk7/tl/hotspot: 27 new changesets
Message-ID: <20090720080947.AC385E81C@hg.openjdk.java.net>

Changeset: 92b5fbbe8477
Author:    xdono
Date:      2009-07-13 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/92b5fbbe8477

Added tag jdk7-b64 for changeset ba36394eb84b

! .hgtags

Changeset: 45c4b1fe45e4
Author:    trims
Date:      2009-07-10 19:10 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/45c4b1fe45e4

6859411: Bump the HS16 build number to 06
Summary: Update the HS16 build number to 06
Reviewed-by: jcoomes

! make/hotspot_version

Changeset: b109e761e927
Author:    kvn
Date:      2009-06-09 16:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b109e761e927

6837472: com/sun/jdi/MonitorFrameInfo.java fails with AggressiveOpts in 6u14
Summary: Disable escape analysis when jvmti/debugger is used. Add support for EA ibto SA.
Reviewed-by: never

! agent/src/share/classes/sun/jvm/hotspot/code/DebugInfoReadStream.java
! agent/src/share/classes/sun/jvm/hotspot/code/MonitorValue.java
+ agent/src/share/classes/sun/jvm/hotspot/code/ObjectValue.java
! agent/src/share/classes/sun/jvm/hotspot/code/ScopeDesc.java
! agent/src/share/classes/sun/jvm/hotspot/code/ScopeValue.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/ObjectReferenceImpl.java
! agent/src/share/classes/sun/jvm/hotspot/jdi/ThreadReferenceImpl.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/CompiledVFrame.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/InterpretedVFrame.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/MonitorInfo.java
! agent/src/share/classes/sun/jvm/hotspot/runtime/StackValue.java
! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaThread.java
! src/share/vm/opto/c2compiler.cpp
! src/share/vm/prims/jvmtiEnvBase.cpp
! src/share/vm/runtime/biasedLocking.cpp
! src/share/vm/runtime/deoptimization.cpp
! src/share/vm/runtime/stackValue.cpp
! src/share/vm/runtime/stackValue.hpp
! src/share/vm/runtime/vframe.cpp
! src/share/vm/runtime/vframe.hpp
! src/share/vm/runtime/vframeArray.cpp
! src/share/vm/runtime/vframe_hp.cpp

Changeset: c6386080541b
Author:    never
Date:      2009-06-10 12:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c6386080541b

6849574: VM crash using NonBlockingHashMap (high_scale_lib)
Reviewed-by: kvn

! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp
! src/share/vm/c1/c1_LIRGenerator.cpp
+ test/compiler/6849574/Test.java

Changeset: 915cc9c5ebc6
Author:    kvn
Date:      2009-06-23 17:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/915cc9c5ebc6

6837094: False positive for "meet not symmetric" failure
Summary: Have the meet not symmetric check recursively do the interface-vs-oop check on array subtypes.
Reviewed-by: jrose
Contributed-by: rasbold at google.com

! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp
+ test/compiler/6837094/Test.java

Changeset: d1fe2c2fbdac
Author:    twisti
Date:      2009-06-17 09:08 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d1fe2c2fbdac

6851829: solaris build fails with 5.8 compilers
Summary: Solaris builds with the CC 5.8 compilers (used for jdk6 update builds) fail while compiling adlc.
Reviewed-by: never

! make/solaris/makefiles/adlc.make

Changeset: e306d7c7222c
Author:    twisti
Date:      2009-06-24 02:09 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e306d7c7222c

Merge


Changeset: 14367225a853
Author:    kvn
Date:      2009-06-24 12:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/14367225a853

6841800: Incorrect boundary values behavior for option -XX:MaxLabelRootDepth=0-6 leads to jvm crash
Summary: MaxLabelRootDepth value less then 10 is invalid.
Reviewed-by: never

! src/share/vm/opto/matcher.cpp

Changeset: 18a08a7e16b5
Author:    twisti
Date:      2009-06-26 07:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/18a08a7e16b5

5057225: Remove useless I2L conversions
Summary: The optimizer should be told to normalize (AndL (ConvI2L x) 0xFF) to (ConvI2L (AndI x 0xFF)), and then the existing matcher rule will work for free.
Reviewed-by: kvn

! src/cpu/sparc/vm/sparc.ad
! src/cpu/x86/vm/x86_32.ad
! src/cpu/x86/vm/x86_64.ad
! src/share/vm/opto/mulnode.cpp
+ test/compiler/5057225/Test5057225.java

Changeset: 8f5825e0aeaa
Author:    never
Date:      2009-06-26 13:03 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8f5825e0aeaa

6818666: G1: Type lost in g1 pre-barrier
Reviewed-by: kvn

! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/graphKit.hpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/parse3.cpp

Changeset: 3f06f139ef53
Author:    never
Date:      2009-06-26 16:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3f06f139ef53

6851908: interpreter null check profiling broken causing extra compilation invalidation
Reviewed-by: kvn

! src/cpu/x86/vm/interp_masm_x86_32.cpp
! src/cpu/x86/vm/interp_masm_x86_64.cpp

Changeset: bf3489cc0aa0
Author:    never
Date:      2009-07-01 12:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bf3489cc0aa0

6856025: assert(_base >= OopPtr && _base <= KlassPtr,"Not a Java pointer")
Reviewed-by: kvn

! src/share/vm/adlc/output_h.cpp
! src/share/vm/opto/graphKit.cpp
! src/share/vm/opto/library_call.cpp
! src/share/vm/opto/parse2.cpp
! src/share/vm/opto/parse3.cpp
! src/share/vm/opto/type.cpp
! src/share/vm/opto/type.hpp

Changeset: b64314863098
Author:    kvn
Date:      2009-07-01 15:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b64314863098

Merge


Changeset: 30b9b25b9cc1
Author:    tonyp
Date:      2009-06-24 11:42 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/30b9b25b9cc1

6850869: G1: RSet "scrubbing" scrubs too much
Summary: RSet scrubbing incorrectly deletes RSet entries that point to regions tagged as "continues humongous" due to a race when RSet scrubbing iterates over regions in parallel.
Reviewed-by: apetrusenko, iveresov

! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: 00f7ec32f290
Author:    apetrusenko
Date:      2009-06-26 09:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/00f7ec32f290

6854027: Precompiled headers are not being updated in Linux/GCC builds
Summary: Fixes incorrect handling of precompiled headers in diff mode.
Reviewed-by: never, twisti

! src/share/tools/MakeDeps/Database.java

Changeset: 3eb9872b10ce
Author:    tonyp
Date:      2009-06-29 12:17 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3eb9872b10ce

6855115: G1: Fix for 6850869 is incorrect
Summary: Missed updating two variable names when improving the code for 6850869.
Reviewed-by: iveresov, jmasa, ysr

! src/share/vm/gc_implementation/g1/concurrentMark.cpp

Changeset: e7d5557ad624
Author:    jmasa
Date:      2009-07-02 16:28 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e7d5557ad624

Merge


Changeset: acba6af809c8
Author:    kvn
Date:      2009-07-01 20:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/acba6af809c8

6840775: Multiple JVM crashes seen with 1.6.0_10 through 1.6.0_14
Summary: Put missed reference to allocated array in copyOf() intrinsic into OopMap for the call slow_arraycopy().
Reviewed-by: never

! agent/src/share/classes/sun/jvm/hotspot/ui/tree/OopTreeNodeAdapter.java
! make/solaris/makefiles/optimized.make
! src/share/vm/opto/block.cpp
! src/share/vm/opto/block.hpp
! src/share/vm/opto/buildOopMap.cpp
! src/share/vm/opto/gcm.cpp
! src/share/vm/opto/library_call.cpp

Changeset: 0f2d888530e7
Author:    cfang
Date:      2009-07-02 16:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0f2d888530e7

6855164: SIGSEGV during compilation of method involving loop over CharSequence.
Summary: Don not split a block if it contains a FastLockNode with a PhiNode input.
Reviewed-by: kvn, never

! src/share/vm/opto/loopopts.cpp

Changeset: 73dac61fe300
Author:    cfang
Date:      2009-07-06 12:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/73dac61fe300

6857707: Add missing test case for CR 6855164 from its bug description.
Summary: Add missing test case for CR 6855164 from its bug description.
Reviewed-by: never

+ test/compiler/6855164/Test.java

Changeset: 4325cdaa78ad
Author:    kvn
Date:      2009-07-06 15:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4325cdaa78ad

6857661: 64-bit server VM: assert(is_Initialize(),"invalid node class")
Summary: Move the secondary raw memory barrier to the correct place in generate_arraycopy().
Reviewed-by: never

! src/share/vm/opto/library_call.cpp

Changeset: f0bd02f95856
Author:    kvn
Date:      2009-07-07 09:54 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f0bd02f95856

Merge


Changeset: 0316eac49d5a
Author:    tonyp
Date:      2009-07-07 14:23 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0316eac49d5a

6855834: G1: minimize the output when -XX:+PrintHeapAtGC is set
Summary: Changing the behavior of -XX:+PrintHeapAtGC for G1 from printing lengthy, per-region information to instead printing a concise summary.
Reviewed-by: ysr, apetrusenko, jcoomes

! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp
! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp
! src/share/vm/gc_implementation/g1/heapRegion.cpp
! src/share/vm/runtime/globals.hpp

Changeset: bb18957ad21e
Author:    ysr
Date:      2009-07-10 16:01 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bb18957ad21e

Merge


Changeset: 218f6b67f9c5
Author:    trims
Date:      2009-07-11 03:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/218f6b67f9c5

Merge


Changeset: ba313800759b
Author:    trims
Date:      2009-07-14 19:43 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ba313800759b

Merge


Changeset: 57c71ad0341b
Author:    xdono
Date:      2009-07-16 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/57c71ad0341b

Added tag jdk7-b65 for changeset ba313800759b

! .hgtags



From tim.bell at sun.com  Mon Jul 20 08:25:01 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 20 Jul 2009 08:25:01 +0000
Subject: hg: jdk7/tl/jaxp: 2 new changesets
Message-ID: <20090720082504.DD724E821@hg.openjdk.java.net>

Changeset: 008c662e0ee9
Author:    xdono
Date:      2009-07-13 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/008c662e0ee9

Added tag jdk7-b64 for changeset a10eec7a1edf

! .hgtags

Changeset: 22f9d5d5b5fe
Author:    xdono
Date:      2009-07-16 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/22f9d5d5b5fe

Added tag jdk7-b65 for changeset 008c662e0ee9

! .hgtags



From tim.bell at sun.com  Mon Jul 20 08:30:24 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 20 Jul 2009 08:30:24 +0000
Subject: hg: jdk7/tl/jaxws: 2 new changesets
Message-ID: <20090720083028.27738E827@hg.openjdk.java.net>

Changeset: aa22a1be5866
Author:    xdono
Date:      2009-07-13 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/aa22a1be5866

Added tag jdk7-b64 for changeset aaa25dfd3de6

! .hgtags

Changeset: fa8712c099ed
Author:    xdono
Date:      2009-07-16 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/fa8712c099ed

Added tag jdk7-b65 for changeset aa22a1be5866

! .hgtags



From tim.bell at sun.com  Mon Jul 20 08:37:52 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 20 Jul 2009 08:37:52 +0000
Subject: hg: jdk7/tl/jdk: 45 new changesets
Message-ID: <20090720084735.CE673E82C@hg.openjdk.java.net>

Changeset: 49e7d22262a9
Author:    ant
Date:      2009-06-18 11:28 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/49e7d22262a9

4788402: SortingFocusTraversalPolicy: prob with non-focusable focus Cycle Root as first
Reviewed-by: dcherepanov

! src/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java
! src/share/classes/javax/swing/SortingFocusTraversalPolicy.java
! test/java/awt/Focus/FocusTraversalPolicy/DefaultFTPTest.java
! test/java/awt/Focus/FocusTraversalPolicy/LayoutFTPTest.java

Changeset: 06f35d090a5e
Author:    langel
Date:      2009-06-19 16:49 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/06f35d090a5e

6721086: Toolkit beep does not work consistently
Summary: Flush out after bell is sounded
Reviewed-by: anthony

! src/solaris/classes/sun/awt/X11/XToolkit.java

Changeset: d1bdaf29e531
Author:    dcherepanov
Date:      2009-06-23 13:35 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d1bdaf29e531

6824169: Need to remove some AWT class dependencies
Reviewed-by: art, anthony, igor, alexp

! src/share/classes/java/awt/AWTEvent.java
! src/share/classes/java/awt/Component.java
! src/share/classes/java/awt/Dialog.java
! src/share/classes/java/awt/EventQueue.java
! src/share/classes/java/awt/MenuComponent.java
! src/share/classes/java/awt/PopupMenu.java
! src/share/classes/java/awt/Window.java
! src/share/classes/javax/swing/BufferStrategyPaintManager.java
! src/share/classes/javax/swing/JLayeredPane.java
! src/share/classes/javax/swing/LayoutFocusTraversalPolicy.java
! src/share/classes/javax/swing/LookAndFeel.java
! src/share/classes/javax/swing/TransferHandler.java
! src/share/classes/javax/swing/UIManager.java
! src/share/classes/javax/swing/text/JTextComponent.java
! src/share/classes/sun/awt/AWTAccessor.java
! src/share/classes/sun/awt/SunToolkit.java
! src/share/classes/sun/awt/shell/ShellFolder.java
- src/share/classes/sun/swing/AccessibleMethod.java
+ src/share/classes/sun/swing/SwingAccessor.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/windows/classes/sun/awt/windows/WComponentPeer.java
! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java
! src/windows/classes/sun/awt/windows/WFileDialogPeer.java
! src/windows/classes/sun/awt/windows/WPopupMenuPeer.java
! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java
! src/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java

Changeset: 61e25d428bfe
Author:    dcherepanov
Date:      2009-06-23 15:10 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/61e25d428bfe

6736247: Component.printAll Invalid local JNI handle
Reviewed-by: anthony

! src/windows/native/sun/windows/awt_Component.cpp
+ test/java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

Changeset: e279dd2c5a2c
Author:    ant
Date:      2009-06-23 15:53 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e279dd2c5a2c

6821291: assertion failure in awt_Frame.h
Reviewed-by: dcherepanov, art

! src/windows/native/sun/windows/awt_Frame.cpp
! src/windows/native/sun/windows/awt_Frame.h

Changeset: 51e452ff726a
Author:    anthony
Date:      2009-06-23 16:10 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/51e452ff726a

6851646: test/closed/java/awt/GridBagLayout/GridBagLayoutIpadXYTest/GridBagLayoutIpadXYTest.java can fail
Summary: Added realSync() call. Made the test public.
Reviewed-by: dcherepanov

+ test/java/awt/GridBagLayout/GridBagLayoutIpadXYTest/GridBagLayoutIpadXYTest.html
+ test/java/awt/GridBagLayout/GridBagLayoutIpadXYTest/GridBagLayoutIpadXYTest.java

Changeset: 5e880ea33ddc
Author:    yan
Date:      2009-06-26 11:48 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5e880ea33ddc

6711676: Numpad keys trigger more than one KeyEvent.
Summary: Introduce a new sniffer based on server keymap.
Reviewed-by: art

! make/sun/xawt/mapfile-vers
! src/solaris/classes/sun/awt/X11/XKeysym.java
! src/solaris/classes/sun/awt/X11/XToolkit.java
! src/solaris/classes/sun/awt/X11/XlibWrapper.java
! src/solaris/classes/sun/awt/X11/keysym2ucs.h
! src/solaris/native/sun/xawt/XlibWrapper.c

Changeset: 60290477fe73
Author:    dav
Date:      2009-06-26 19:50 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/60290477fe73

6848458: java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java fails
Summary: consider gap between the component edge and container borders instead of just getX() and getY()
Reviewed-by: dav
Contributed-by: mwong at redhat.com

! test/java/awt/GridLayout/LayoutExtraGaps/LayoutExtraGaps.java

Changeset: 2df0d81c4201
Author:    ant
Date:      2009-06-30 12:55 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2df0d81c4201

6855713: jdk7: debug build failure in awt_Frame.cpp
Reviewed-by: dcherepanov, yan

! src/windows/native/sun/windows/awt_Frame.cpp

Changeset: 75497b840ed0
Author:    yan
Date:      2009-06-30 02:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/75497b840ed0

Merge

- src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/IBM1381.java
- src/share/classes/sun/nio/cs/ext/IBM1383.java
- src/share/classes/sun/nio/cs/ext/IBM930.java
- src/share/classes/sun/nio/cs/ext/IBM933.java
- src/share/classes/sun/nio/cs/ext/IBM935.java
- src/share/classes/sun/nio/cs/ext/IBM937.java
- src/share/classes/sun/nio/cs/ext/IBM939.java
- src/share/classes/sun/nio/cs/ext/IBM942.java
- src/share/classes/sun/nio/cs/ext/IBM943.java
- src/share/classes/sun/nio/cs/ext/IBM948.java
- src/share/classes/sun/nio/cs/ext/IBM949.java
- src/share/classes/sun/nio/cs/ext/IBM950.java
- src/share/classes/sun/nio/cs/ext/IBM970.java
- src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java
- src/share/native/sun/font/bidi/cmemory.h
- src/share/native/sun/font/bidi/jbidi.c
- src/share/native/sun/font/bidi/jbidi.h
- src/share/native/sun/font/bidi/ubidi.c
- src/share/native/sun/font/bidi/ubidi.h
- src/share/native/sun/font/bidi/ubidiimp.h
- src/share/native/sun/font/bidi/ubidiln.c
- src/share/native/sun/font/bidi/uchardir.c
- src/share/native/sun/font/bidi/uchardir.h
- src/share/native/sun/font/bidi/utypes.h

Changeset: 4d7e08935d95
Author:    yan
Date:      2009-07-01 00:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4d7e08935d95

Merge

- src/share/classes/sun/swing/AccessibleMethod.java

Changeset: 743021a4938c
Author:    peterz
Date:      2009-06-22 18:08 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/743021a4938c

6849277: Nimbus L&F: lots of painter classes were added to JDK7 as public
Reviewed-by: malenkov

! src/share/classes/javax/swing/plaf/nimbus/Defaults.template
! src/share/classes/javax/swing/plaf/nimbus/PainterImpl.template

Changeset: ce347002bbd9
Author:    peterz
Date:      2009-06-23 12:24 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ce347002bbd9

6844273: jdk/make/docs/CORE_PKGS.gmk does not list Nimbus
Reviewed-by: prr

! make/docs/CORE_PKGS.gmk
! src/share/classes/javax/swing/plaf/nimbus/package.html

Changeset: b75fc6019d5f
Author:    malenkov
Date:      2009-06-24 13:59 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b75fc6019d5f

6852574: EnumPersistenceDelegate fails to persist instances with blocks
Reviewed-by: peterz

! src/share/classes/java/beans/MetaData.java
+ test/java/beans/XMLEncoder/Test6852574.java

Changeset: 404a13b063f9
Author:    malenkov
Date:      2009-06-24 17:45 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/404a13b063f9

6737700: api/javax_swing/table/DefaultTableCellRenderer/index.html#getset:DefaultTableCellRenderer
Reviewed-by: alexp

! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java

Changeset: e006119341de
Author:    peytoia
Date:      2009-06-25 07:38 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e006119341de

6853792: test/java/text/Bidi/Bug6850113.java compilation error
Reviewed-by: okutsu

! test/java/text/Bidi/Bug6850113.java

Changeset: d6f2dd2bd8d0
Author:    peytoia
Date:      2009-06-25 17:37 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d6f2dd2bd8d0

6609750: [Fmt-De] SimpleDateFormat.format() doesn't handle pattern "y" correctly
Reviewed-by: okutsu

! src/share/classes/java/text/SimpleDateFormat.java
+ test/java/text/Format/DateFormat/Bug6609750.java

Changeset: d086e324775c
Author:    yan
Date:      2009-06-25 00:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d086e324775c

Merge

- src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/IBM1381.java
- src/share/classes/sun/nio/cs/ext/IBM1383.java
- src/share/classes/sun/nio/cs/ext/IBM930.java
- src/share/classes/sun/nio/cs/ext/IBM933.java
- src/share/classes/sun/nio/cs/ext/IBM935.java
- src/share/classes/sun/nio/cs/ext/IBM937.java
- src/share/classes/sun/nio/cs/ext/IBM939.java
- src/share/classes/sun/nio/cs/ext/IBM942.java
- src/share/classes/sun/nio/cs/ext/IBM943.java
- src/share/classes/sun/nio/cs/ext/IBM948.java
- src/share/classes/sun/nio/cs/ext/IBM949.java
- src/share/classes/sun/nio/cs/ext/IBM950.java
- src/share/classes/sun/nio/cs/ext/IBM970.java
- src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java

Changeset: 4d54d6e7bcef
Author:    yan
Date:      2009-06-25 02:42 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4d54d6e7bcef

Merge


Changeset: e0707baa1593
Author:    peytoia
Date:      2009-06-25 21:55 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e0707baa1593

6792400: Avoid loading of Normalizer resources for simple uses
Reviewed-by: okutsu

! src/share/classes/sun/text/normalizer/NormalizerBase.java

Changeset: ae9e74a17059
Author:    malenkov
Date:      2009-06-25 18:50 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ae9e74a17059

6848364: javax/swing/border/Test4856008.java regression test fails due to BorderedComponent package not found
Reviewed-by: alexp

! test/javax/swing/border/Test4856008.java

Changeset: f1f9d228800e
Author:    peterz
Date:      2009-06-26 08:09 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f1f9d228800e

6827032: NIMBUS: Drag and drop throws a NPE in SwingSet2 ColorChooser
Reviewed-by: malenkov

! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java

Changeset: e60d3354ab9f
Author:    malenkov
Date:      2009-06-26 16:30 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e60d3354ab9f

6557223: Resize cursor stays after fast outline-resize of JInternalFrame with JScrollPane
Reviewed-by: peterz

! src/share/classes/javax/swing/plaf/basic/BasicInternalFrameUI.java

Changeset: 1b40ddc3688c
Author:    malenkov
Date:      2009-06-26 16:58 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1b40ddc3688c

6679840: provide a way to choose v-synced BufferStrategy
Reviewed-by: peterz

! src/share/classes/com/sun/java/swing/SwingUtilities3.java
! src/share/classes/javax/swing/BufferStrategyPaintManager.java

Changeset: 800082d9b8df
Author:    malenkov
Date:      2009-06-26 17:15 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/800082d9b8df

6742850: Antialiasing for GTK L&F should be turned on by default if there is no embedded bitmap.
Reviewed-by: peterz

! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java

Changeset: 95f3fb73cf60
Author:    peterz
Date:      2009-06-26 21:43 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/95f3fb73cf60

6849805: Nimbus L&F: NimbusLookAndFeel.getDerivedColor() not always returns color2 for 1.0 midPoint
Summary: Different rounding mode used for float->int conversion
Reviewed-by: malenkov

! src/share/classes/javax/swing/plaf/nimbus/AbstractRegionPainter.java
! src/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java
+ test/javax/swing/plaf/nimbus/Test6849805.java

Changeset: 0bc2fa2d1938
Author:    peytoia
Date:      2009-06-30 09:38 +0900
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0bc2fa2d1938

6855715: Font2Dtest demo needs to be updated to support Unicode 5.1.0.
Reviewed-by: okutsu

! src/share/demo/jfc/Font2DTest/RangeMenu.java

Changeset: 9be953f877a8
Author:    yan
Date:      2009-07-01 00:23 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9be953f877a8

Merge

! src/share/classes/javax/swing/BufferStrategyPaintManager.java

Changeset: 1a52b17a18d2
Author:    yan
Date:      2009-07-07 23:12 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1a52b17a18d2

Merge

- src/share/classes/sun/swing/AccessibleMethod.java

Changeset: 9053bcc8eef0
Author:    herrick
Date:      2009-06-12 14:56 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9053bcc8eef0

6797688: Umbrella: Merge all JDK 6u4 - 6u12 deployment code into JDK7
6845973: Update JDK7 with deployment changes in 6u13, 6u14
4802695: Support 64-bit Java Plug-in and Java webstart on Windows/Linux on AMD64
6825019: DownloadManager should not be loaded and referenced for full JRE
6738770: REGRESSION:JSException throws when use LiveConnect javascript facility
6772884: plugin2 : java.lang.OutOfMemoryError or crash
6707535: Crossing domain hole affecting multiple sites/domains using plug-in
6728071: Non-verification of Update files may allow unintended updates
6704154: Code loaded from local filesystem should not get access to localhost
6727081: Web Start security restrictions bypass using special extension jnlp
6727079: Java Web Start Socket() restriction bypass
6727071: Cache location/user name information disclosure in SingleInstanceImpl.
6716217: AppletClassLoader adds permissions based on codebase regardless of CS
6694892: Java Webstart inclusion via system properties override [CVE-2008-2086]
6704074: localhost socket access due to cache location exposed
6703909: Java webstart arbitrary file creation using nativelib
6665315: browser crashes when deployment.properties has more slashes ( / )
6660121: Encoding values in JNLP files can cause buffer overflow
6606110: URLConnection.setProxiedHost for resources that are loaded via proxy
6581221: SSV(VISTA): Redirection FAILS to work if user does a downgrade install
6609756: Buffer Overflow in Java ActiveX component
6608712: Bypassing the same origin policy in Java with crafted names
6534630: "gnumake clobber" doesn't
6849953: JDK7 - replacement of bufferoverflowU.lib on amd64 breaks build
6849029: Need some JDK7 merge clean-up after comments on the webrev
6847582: Build problem on JDK7 with isSecureProperty in merge
6827935: JDK 7 deployment merging - problem in Compiler-msvm.gmk
6823215: latest merge fixes from 6u12 -> JDK7
6816153: further mergers for JDK7 deployment integration
6807074: Fix Java Kernel and JQS in initial JDK7 builds
Summary: Initial changeset for implementing 6uX Deployment Features into JDK7
Reviewed-by: dgu, billyh

! make/com/sun/java/pack/Makefile
! make/common/Defs-windows.gmk
! make/common/Library.gmk
! make/common/Program.gmk
! make/common/Release.gmk
! make/common/shared/Compiler-msvc.gmk
! make/common/shared/Defs-utils.gmk
! make/common/shared/Defs-windows.gmk
! make/common/shared/Defs.gmk
! make/common/shared/Sanity.gmk
! make/java/java/FILES_c.gmk
! make/java/redist/Makefile
! make/jpda/tty/Makefile
! make/sun/Makefile
! make/sun/applet/Makefile
! make/sun/jar/Makefile
! make/sun/javazic/tzdata_jdk/jdk11_full_backward
! make/sun/jconsole/Makefile
+ make/sun/jkernel/FILES_c_windows.gmk
+ make/sun/jkernel/FILES_java.gmk
+ make/sun/jkernel/Makefile
! make/sun/native2ascii/Makefile
! make/sun/rmi/rmic/Makefile
! make/sun/serialver/Makefile
! src/share/classes/java/awt/color/ICC_Profile.java
! src/share/classes/java/lang/ClassLoader.java
! src/share/classes/java/lang/System.java
! src/share/classes/java/util/zip/ZipEntry.java
! src/share/classes/sun/applet/AppletClassLoader.java
! src/share/classes/sun/applet/AppletPanel.java
+ src/share/classes/sun/jkernel/BackgroundDownloader.java
+ src/share/classes/sun/jkernel/Bundle.java
+ src/share/classes/sun/jkernel/BundleCheck.java
+ src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java
+ src/share/classes/sun/jkernel/DigestOutputStream.java
+ src/share/classes/sun/jkernel/DownloadManager.java
+ src/share/classes/sun/jkernel/KernelError.java
+ src/share/classes/sun/jkernel/Mutex.java
+ src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java
+ src/share/classes/sun/jkernel/StandaloneMessageDigest.java
+ src/share/classes/sun/jkernel/StandaloneSHA.java
! src/share/classes/sun/management/OperatingSystemImpl.java
! src/share/classes/sun/management/ThreadImpl.java
! src/share/classes/sun/misc/Launcher.java
! src/share/classes/sun/misc/PerformanceLogger.java
! src/share/classes/sun/misc/VM.java
! src/share/native/common/jni_util.c
! src/share/native/common/jni_util.h
! src/share/native/sun/misc/VM.c
+ src/solaris/native/common/jni_util_md.c
! src/windows/bin/java_md.c
+ src/windows/native/common/jni_util_md.c
+ src/windows/native/sun/jkernel/DownloadDialog.cpp
+ src/windows/native/sun/jkernel/DownloadDialog.h
+ src/windows/native/sun/jkernel/DownloadHelper.cpp
+ src/windows/native/sun/jkernel/DownloadHelper.h
+ src/windows/native/sun/jkernel/graphics/bullet.bmp
+ src/windows/native/sun/jkernel/graphics/cautionshield32.bmp
+ src/windows/native/sun/jkernel/graphics/java-icon.ico
+ src/windows/native/sun/jkernel/graphics/masthead.bmp
+ src/windows/native/sun/jkernel/graphics/warningmasthead.bmp
+ src/windows/native/sun/jkernel/kernel.cpp
+ src/windows/native/sun/jkernel/kernel.def
+ src/windows/native/sun/jkernel/kernel.h
+ src/windows/native/sun/jkernel/kernel.rc
+ src/windows/native/sun/jkernel/kernel_de.rc
+ src/windows/native/sun/jkernel/kernel_en.rc
+ src/windows/native/sun/jkernel/kernel_es.rc
+ src/windows/native/sun/jkernel/kernel_fr.rc
+ src/windows/native/sun/jkernel/kernel_it.rc
+ src/windows/native/sun/jkernel/kernel_ja.rc
+ src/windows/native/sun/jkernel/kernel_ko.rc
+ src/windows/native/sun/jkernel/kernel_sv.rc
+ src/windows/native/sun/jkernel/kernel_zh.rc
+ src/windows/native/sun/jkernel/kernel_zh_TW.rc
+ src/windows/native/sun/jkernel/resource.h
+ src/windows/native/sun/jkernel/stdafx.cpp
+ src/windows/native/sun/jkernel/stdafx.h
+ src/windows/native/sun/jkernel/version.rc
! src/windows/native/sun/windows/awt.rc
+ src/windows/resource/unpack200_proto.exe.manifest
! src/windows/resource/version.rc
! test/java/awt/Focus/NonFocusableWindowTest/NoEventsTest.java
! test/java/awt/Focus/RestoreFocusOnDisabledComponentTest/RestoreFocusOnDisabledComponentTest.java
! test/java/awt/font/Rotate/TranslatedOutlineTest.java
! test/java/awt/font/Threads/FontThread.java
! test/java/security/AccessControlContext/FailureDebugOption.java
! test/javax/swing/JPopupMenu/6691503/bug6691503.java
! test/sun/security/pkcs11/Cipher/TestRSACipherWrap.java
! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/AsyncSSLSocketClose.java
! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CloseKeepAliveCached.java

Changeset: ea7620b05a58
Author:    herrick
Date:      2009-06-15 13:08 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ea7620b05a58

Merge

! make/common/shared/Defs-windows.gmk
! make/common/shared/Defs.gmk
! make/common/shared/Sanity.gmk

Changeset: 4f207797e185
Author:    herrick
Date:      2009-06-19 11:46 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4f207797e185

6852646: JDK 7 cannot build w/o ALT_HOTSPOT_KERNEL_PATH set.
Summary: This problem was discovered testing initial changeset for implementing 6uX Deployment Features into JDK7
Reviewed-by: dgu, billyh

! make/common/shared/Defs-windows.gmk
! make/common/shared/Sanity.gmk

Changeset: 23c7d780c1b3
Author:    herrick
Date:      2009-06-19 15:04 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/23c7d780c1b3

6853152: JDK 7 cannot build w/o ALT_HOTSPOT_KERNEL_PATH set. - still broken
Summary: This problem was discovered testing initial changeset for implementing 6uX Deployment Features into JDK7
Reviewed-by: dgu, billyh

! make/common/shared/Defs-windows.gmk
! make/java/redist/Makefile

Changeset: f509fe92a102
Author:    herrick
Date:      2009-06-22 09:16 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f509fe92a102

Merge


Changeset: 9362d0114c3a
Author:    herrick
Date:      2009-06-24 14:49 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9362d0114c3a

6633813: Add standard hotspot import path for Kernel VM
Summary: This problem was discovered testing initial changeset for implementing 6uX Deployment Features into JDK7
Reviewed-by: dgu, billyh

! make/common/shared/Defs-windows.gmk
! make/java/redist/Makefile

Changeset: dd0371861841
Author:    herrick
Date:      2009-06-29 12:06 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd0371861841

Merge

! make/common/Release.gmk
! make/sun/Makefile
! src/share/classes/java/lang/System.java
- src/share/classes/sun/nio/cs/ext/DBCSDecoderMapping.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_ASCII_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_IBM_EBCDIC_Encoder.java
- src/share/classes/sun/nio/cs/ext/DBCS_ONLY_IBM_EBCDIC_Decoder.java
- src/share/classes/sun/nio/cs/ext/IBM1381.java
- src/share/classes/sun/nio/cs/ext/IBM1383.java
- src/share/classes/sun/nio/cs/ext/IBM930.java
- src/share/classes/sun/nio/cs/ext/IBM933.java
- src/share/classes/sun/nio/cs/ext/IBM935.java
- src/share/classes/sun/nio/cs/ext/IBM937.java
- src/share/classes/sun/nio/cs/ext/IBM939.java
- src/share/classes/sun/nio/cs/ext/IBM942.java
- src/share/classes/sun/nio/cs/ext/IBM943.java
- src/share/classes/sun/nio/cs/ext/IBM948.java
- src/share/classes/sun/nio/cs/ext/IBM949.java
- src/share/classes/sun/nio/cs/ext/IBM950.java
- src/share/classes/sun/nio/cs/ext/IBM970.java
- src/share/classes/sun/nio/cs/ext/SimpleEUCDecoder.java
- src/share/native/sun/font/bidi/cmemory.h
- src/share/native/sun/font/bidi/jbidi.c
- src/share/native/sun/font/bidi/jbidi.h
- src/share/native/sun/font/bidi/ubidi.c
- src/share/native/sun/font/bidi/ubidi.h
- src/share/native/sun/font/bidi/ubidiimp.h
- src/share/native/sun/font/bidi/ubidiln.c
- src/share/native/sun/font/bidi/uchardir.c
- src/share/native/sun/font/bidi/uchardir.h
- src/share/native/sun/font/bidi/utypes.h

Changeset: 4caa574b3993
Author:    herrick
Date:      2009-06-29 17:34 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4caa574b3993

6855953: JDK7 - merger error of deployment changes with b62 -in jdk/make/sun/Makefile
Summary: This problem was discovered testing initial changeset for implementing 6uX Deployment Features into JDK7
Reviewed-by: dgu, billyh

! make/sun/Makefile

Changeset: 9710ed723163
Author:    herrick
Date:      2009-07-01 10:18 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9710ed723163

Merge

! src/share/classes/java/awt/color/ICC_Profile.java

Changeset: c51ead46c547
Author:    herrick
Date:      2009-07-06 14:10 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c51ead46c547

Merge

! make/common/Release.gmk
- src/share/classes/java/nio/file/DirectoryStreamFilters.java
- src/share/classes/java/nio/file/FileAction.java
- src/share/classes/java/nio/file/spi/AbstractPath.java
- src/share/classes/sun/io/ByteToCharMS932DB.java
- src/share/classes/sun/io/CharToByteMS932DB.java
- src/share/classes/sun/nio/cs/ext/EUC_CN.java
- src/share/classes/sun/nio/cs/ext/EUC_KR.java
- src/share/classes/sun/nio/cs/ext/GBK.java
- src/share/classes/sun/nio/cs/ext/Johab.java
- src/share/classes/sun/nio/cs/ext/MS932.java
- src/share/classes/sun/nio/cs/ext/MS932DB.java
- src/share/classes/sun/nio/cs/ext/MS936.java
- src/share/classes/sun/nio/cs/ext/MS949.java
- src/share/classes/sun/nio/cs/ext/MS950.java
- src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java
- src/share/classes/sun/nio/fs/MimeType.java
- test/java/nio/file/DirectoryStream/Filters.java
- test/java/nio/file/Files/content_type.sh
- test/java/nio/file/Path/temporary_files.sh
- test/java/nio/file/attribute/Attributes/Basic.java

Changeset: a50217eb3ee1
Author:    jqzuo
Date:      2009-07-09 13:53 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a50217eb3ee1

Merge

- src/share/classes/sun/swing/AccessibleMethod.java

Changeset: 382a27aa78d3
Author:    xdono
Date:      2009-07-13 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/382a27aa78d3

Added tag jdk7-b64 for changeset a50217eb3ee1

! .hgtags

Changeset: 53b27ac4f706
Author:    tbell
Date:      2009-07-13 23:58 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/53b27ac4f706

Merge

! make/common/Defs-windows.gmk

Changeset: 6ec0174d4f36
Author:    xdono
Date:      2009-07-16 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6ec0174d4f36

Added tag jdk7-b65 for changeset 382a27aa78d3

! .hgtags

Changeset: 51ccb32e6d14
Author:    tbell
Date:      2009-07-16 18:07 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/51ccb32e6d14

Merge


Changeset: 3acfd7c1f984
Author:    tbell
Date:      2009-07-17 09:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3acfd7c1f984

Merge




From tim.bell at sun.com  Mon Jul 20 09:02:08 2009
From: tim.bell at sun.com (tim.bell at sun.com)
Date: Mon, 20 Jul 2009 09:02:08 +0000
Subject: hg: jdk7/tl/langtools: 7 new changesets
Message-ID: <20090720090223.7A626E831@hg.openjdk.java.net>

Changeset: e4a1c76c1abb
Author:    peterz
Date:      2009-06-23 12:24 +0400
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e4a1c76c1abb

6844273: jdk/make/docs/CORE_PKGS.gmk does not list Nimbus
Reviewed-by: prr

! src/share/classes/com/sun/tools/javac/resources/legacy.properties

Changeset: ddef2ef424d8
Author:    yan
Date:      2009-06-25 00:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ddef2ef424d8

Merge

- make/README
- src/share/classes/sun/tools/javap/AttrData.java
- src/share/classes/sun/tools/javap/CPX.java
- src/share/classes/sun/tools/javap/CPX2.java
- src/share/classes/sun/tools/javap/ClassData.java
- src/share/classes/sun/tools/javap/Constants.java
- src/share/classes/sun/tools/javap/FieldData.java
- src/share/classes/sun/tools/javap/InnerClassData.java
- src/share/classes/sun/tools/javap/JavapEnvironment.java
- src/share/classes/sun/tools/javap/JavapPrinter.java
- src/share/classes/sun/tools/javap/LineNumData.java
- src/share/classes/sun/tools/javap/LocVarData.java
- src/share/classes/sun/tools/javap/Main.java
- src/share/classes/sun/tools/javap/MethodData.java
- src/share/classes/sun/tools/javap/RuntimeConstants.java
- src/share/classes/sun/tools/javap/StackMapData.java
- src/share/classes/sun/tools/javap/StackMapTableData.java
- src/share/classes/sun/tools/javap/Tables.java
- src/share/classes/sun/tools/javap/TrapData.java
- src/share/classes/sun/tools/javap/TypeSignature.java
- test/tools/javac/code/ArrayClone.sh
- test/tools/javap/ListTest.java
- test/tools/javap/OptionTest.java

Changeset: 09dc14c713f0
Author:    yan
Date:      2009-07-01 00:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/09dc14c713f0

Merge


Changeset: d8f23a81d46f
Author:    yan
Date:      2009-07-07 23:13 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d8f23a81d46f

Merge


Changeset: 7e0056ded28c
Author:    xdono
Date:      2009-07-13 14:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7e0056ded28c

Added tag jdk7-b64 for changeset d8f23a81d46f

! .hgtags

Changeset: 634f519d6f9a
Author:    xdono
Date:      2009-07-16 10:53 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/634f519d6f9a

Added tag jdk7-b65 for changeset 7e0056ded28c

! .hgtags

Changeset: 86ad2753f3be
Author:    tbell
Date:      2009-07-17 09:14 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/86ad2753f3be

Merge




From Ulf.Zibis at gmx.de  Mon Jul 20 10:37:48 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Mon, 20 Jul 2009 12:37:48 +0200
Subject: My first webrev review request: 6850337 Hasher.java interprets
	given option value badly
In-Reply-To: <17c6771e0907191725v3d818580idf94b905d9def198@mail.gmail.com>
References: <4A631335.4080400@gmx.de>
	<17c6771e0907191725v3d818580idf94b905d9def198@mail.gmail.com>
Message-ID: <4A6448FC.7080509@gmx.de>

Hi Andrew,

thanks for looking at my request. ....

Am 20.07.2009 02:25, Andrew John Hughes schrieb:
> 2009/7/19 Ulf Zibis <Ulf.Zibis at gmx.de>:
>   
>> Martin, Sherman, Neal,
>>
>> do you like to sponsor and review my CR ?
>>
>> Don't worry, it's very simple and small, best for getting familiar with the
>> workflow.
>>
>> See:
>> https://bugs.openjdk.java.net/show_bug.cgi?id=100090
>>
>> Thanks,
>>
>> Ulf
>>
>>
>>
>>
>>     
>
> As this bug is about a tool used during the build, your mail probably
> wants to be directed to the build list.
>   

Good idea, thanks for forwarding.

> Are you sure this is not done by design and that mb is not in fact
> meant to be an exclusive rather than inclusive bound?
>   

Option usage of Hasher.java says:
"    -md depth    max chain depth (default 3)"
"    -mb bits     max index bits (lg of table size, default 10)"
In case of setting -md to x the max chain depth properly results in x, 
but ...
in case of setting -mb to x the max lg of table size inproperly results 
in x-1 bits, as you can see in -verbose output of the hasher.

To ensure, that the default value is processed as it would be 10, 
variable maxBits is pre-set to 11, to "workaround" the bug.
When fixing this bug, any usage of this option should be corrected to 
x-1 to ensure identical results.

I don't think the different boundary behaviour of -md and -mb is done by 
design. Maybe processing of -md has been wrong too in first time and was 
corrected, but correction for -mb was overseen, as never used.

Maybe you could have a short call to the author Mark Reynolds to ensure 
this. Possibly he also has knowledge of other usage than in 
genCharsetProvider.sh.

> Have you checked that the OpenJDK can still be built with this change in place?
>   

I have scanned over
- hg.openjdk.java.net/jdk7/tl/jdk/make
- hg.openjdk.java.net/jdk7/tl/jdk/src
- hg.openjdk.java.net/jdk7/tl/jdk/test

The only usage of Hasher.java I've found in:
- hg.openjdk.java.net/jdk7/tl/jdk/make/java/nio/genCharsetProvider.sh

In this case, the option -mb  is not used. I assume, this is the reason, 
why nobody has experienced this bug before.

I have *not* scanned over
- hg.openjdk.java.net/jdk7/tl/hotspot .../langtools etc.
as I don't have a hg clone of them.

Maybe I should have done this, but I think, it's anyway good that 
experienced SUN engineer would do that scan too, and I guess, you have 
better tools to do that.

-Ulf




From Jean-Christophe.Collet at Sun.COM  Mon Jul 20 17:43:32 2009
From: Jean-Christophe.Collet at Sun.COM (Jean-Christophe Collet)
Date: Mon, 20 Jul 2009 19:43:32 +0200
Subject: How to contribute - webrev question
In-Reply-To: <4A60AE73.3080706@gmx.de>
References: <810fb9ac0907150123v48d8d002xa45b10f95a6b05cc@mail.gmail.com>
	<4A5EF027.2050903@redhat.com> <4A5EF419.9090104@gmx.de>
	<4A5EF4CF.9050903@redhat.com> <4A5EFB35.20305@gmx.de>
	<4A5EFBE1.1030808@redhat.com> <4A5EFEB5.1070205@gmx.de>
	<4A5F2C2A.6040103@gmx.de>
	<17c6771e0907160657i2228c149i7c14b73f3e4a33a2@mail.gmail.com>
	<4A5FD283.1040408@gmx.de>
	<1ccfd1c10907161849q205b9dbew6e67cd32dea7ce04@mail.gmail.com>
	<4A5FDE50.4080107@gmx.de> <4A6059E1.3060409@sun.com>
	<4A606BDA.5090207@gmx.de> <4A60AE73.3080706@gmx.de>
Message-ID: <4A64ACC4.6070501@sun.com>

Ulf Zibis wrote:
> Hi all,
>
> I'm very happy to successful run webrev on Windows :-)
> Much thanks you all.
>
> Now I have some errors when trying to 'webrev' a single file 'README' 
> from my workspace.
> I'm afraid, I don't understand, how to define a 'filelist'.
> So please give me additional hint.
>

A 'filelist' is a file that contains a list of file :-)
1 line per file, paths relative to the top of the workspace.


> Here is what I tried:
>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> ich at Mobi ~
> $ dir /cygdrive
> c  d  e
>
> ich at Mobi ~
> $ cd /cygdrive/c/Projects/OpenJDK7/jdk
>
> ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
> $ dir
> ASSEMBLY_EXCEPTION  README              build  make  test
> LICENSE             THIRD_PARTY_README  dist   src   webrev
>
> ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
> $ /usr/local/bin/webrev -b -o ../webrev -u UlfZibis README
>   SCM detected: mercurial
> File list from: README
>      Workspace: c:/Projects/OpenJDK7/jdk
> Compare against: C:/Projects/Repositories/OpenJDK7-tl_jdk/jdk
>      Output to: /cygdrive/c/Projects/OpenJDK7/jdk/../webrev
>   Output Files:
> abort: cannot follow nonexistent file: "README:"
>        README:
>                *** Error: file not in parent or child
> abort: cannot follow nonexistent file: "This"
>        This
>                *** Error: file not in parent or child
> abort: cannot follow nonexistent file: "See"
>        See
>                *** Error: file not in parent or child
> abort: cannot follow nonexistent file: "Simple"
>        Simple
>                *** Error: file not in parent or child
> abort: cannot follow nonexistent file: "1."
>        1.
>                *** Error: file not in parent or child
> mkdir: cannot create directory `c:/Projects/OpenJDK7/jdk/http:': No 
> such file or
> directory
>        http://java.sun.com/javase/downloads/index.jsp
>                mkdir: cannot create directory 
> `/cygdrive/c/Projects/OpenJDK7/jd
> k/../webrev/http:': No such file or directory
> /usr/local/bin/webrev[2873]: cd: 
> c:/Projects/OpenJDK7/jdk/http:/java.sun.com/jav
> ase/downloads - No such file or directory
> mkdir: cannot create directory 
> `/cygdrive/c/Projects/OpenJDK7/jdk/../webrev/raw_
> files/old/http:': No such file or directory
> mkdir: cannot create directory 
> `/cygdrive/c/Projects/OpenJDK7/jdk/../webrev/raw_
> files/new/http:': No such file or directory
> *** Error: file not in parent or child
> abort: cannot follow nonexistent file: "Set"
>        Set
>                *** Error: file not in parent or child
> abort: cannot follow nonexistent file: "2."
>        2.
>                *** Error: file not in parent or child
> abort: cannot follow nonexistent file: "You'll"
>        You'll
>                *** Error: file not in parent or child
> abort: cannot follow nonexistent file: "bcel.jar"
>        bcel.jar
>                *** Error: file not in parent or child
> abort: cannot follow nonexistent file: "jibx-bind.jar"
>        jibx-bind.jar
>                *** Error: file not in parent or child
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>       ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
> $ /usr/local/bin/webrev -h
> /usr/local/bin/webrev[2107]: -h: unknown option
> Usage:  webrev [common-options]
>        webrev [common-options] ( <file> | - )
>        webrev [common-options] -w <wx file>
>        webrev [common-options] -l [arguments to 'putback']
>
> Options:
>        -v: Print the version of this tool.
>        -b: Do not ignore changes in the amount of white space.
>        -c <CR#>: Include link to CR (aka bugid) in the main page.
>        -i <filename>: Include <filename> in the index.html file.
>        -o <outdir>: Output webrev to specified directory.
>        -p <compare-against>: Use specified parent wkspc or basis for 
> comparison
>
>        -w <wxfile>: Use specified wx active file.
>        -u <username>: Use that username instead of 'guessing' one.
>        -m: Forces the use of Mercurial
>        -t: Forces the use of Teamware
>
> Mercurial only options:
>        -r rev: Compare against a specified revision
>        -N: Skip 'hg outgoing', use only 'hg status'
>        -f: Use the forest extension
>
> Environment:
>        WDIR: Control the output directory.
>        WEBREV_BUGURL: Control the URL prefix for bugids.
>        WEBREV_SACURL: Control the URL prefix for ARC cases.
>
> SCM Environment:
>        Teamware: CODEMGR_WS: Workspace location.
>        Teamware: CODEMGR_PARENT: Parent workspace location.
>
> Contact: jean-christophe.collet at sun.com for issues and bug reports.
>
>
> ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
> $ /usr/local/bin/webrev -b -o ../webrev -u UlfZibis < README | - >
> bash: syntax error near unexpected token `newline'
>
> ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
> $ /usr/local/bin/webrev -b -o ../webrev -u UlfZibis README | -
> bash: -: command not found
>   SCM detected: mercurial
> File list from: README
>
> ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
> $ /usr/local/bin/webrev -b -o ../webrev -u UlfZibis < <README> | - >
> bash: syntax error near unexpected token `<'
>
> ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
> $ /usr/local/bin/webrev -b -o ../webrev -u UlfZibis < <README> | -
> bash: syntax error near unexpected token `<'
>
> ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
> $ /usr/local/bin/webrev -b -o ../webrev -u UlfZibis < README | -
> bash: -: command not found
>   SCM detected: mercurial
>
> ich at Mobi /cygdrive/c/Projects/OpenJDK7/jdk
> $ /usr/local/bin/webrev -b -o ../webrev -u UlfZibis < README
>   SCM detected: mercurial
>      Workspace: c:/Projects/OpenJDK7/jdk
> Compare against: C:/Projects/Repositories/OpenJDK7-tl_jdk/jdk
>      Output to: /cygdrive/c/Projects/OpenJDK7/jdk/../webrev
>   Output Files:
>        .hgtags
>                 patch new
>        README
>                 patch new
>        make/Makefile
>                 patch new
>        make/com/sun/Makefile
>                 patch new
>        make/common/Defs-linux.gmk
>                 patch new
>        make/common/Defs-solaris.gmk
>                 patch new
>        make/common/Defs-windows.gmk
>                 patch new
> $
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
>
> Am 17.07.2009 14:17, Ulf Zibis schrieb:
>> Am 17.07.2009 13:00, Dalibor Topic schrieb:
>>> Ulf Zibis wrote:
>>>  
>>>> Much thanks, Martin, to rub my eyes.
>>>>
>>>> I'm successive with Cygwin to run awk scripts on Windows, but there is
>>>> no library for ksh (Kern Shell) :-(
>>>>     
>>>
>>> There is pdksh, fwiw: http://cygwin.com/packages/pdksh/pdksh-5.2.14-3
>>> but it may or may not work. It may be worth a try, of course.
>>>
>>>   
>>
>> Oops, I've overseen this in the list, because it starts with a 'p'.
>> Much thanks Dalibor,
>>
>> -Ulf
>>
>>
>>
>



From Xueming.Shen at Sun.COM  Mon Jul 20 18:18:02 2009
From: Xueming.Shen at Sun.COM (Xueming Shen)
Date: Mon, 20 Jul 2009 11:18:02 -0700
Subject: My first webrev review request: 6850337 Hasher.java interprets
	given option value badly
In-Reply-To: <4A6448FC.7080509@gmx.de>
References: <4A631335.4080400@gmx.de>
	<17c6771e0907191725v3d818580idf94b905d9def198@mail.gmail.com>
	<4A6448FC.7080509@gmx.de>
Message-ID: <4A64B4DA.2020103@sun.com>

Ulf,

I believe the "mb" is designed to be "exclusive". I'm the one to blame, 
I changed the
default mb value from 10 to 11 for my 1.6 Console work, which moved all OEM
charsets from the "extended" into the "standard" therefor required a 
bigger default
value, but I FORGOT to update the help message as well. My bad. I guess the
better fix for this one is to update the err.println(...). I will be the 
sponsor if you still
want to "fix" this one.

Sherman

btw,
(1) The bugid# which I updated the mb from 10 to 11 is #6349456.
(2) So far the "convention" is to put the contributor name into the hg 
commit message not
the source file.

Ulf Zibis wrote:
>
>
>> Are you sure this is not done by design and that mb is not in fact
>> meant to be an exclusive rather than inclusive bound?
>>   
>
> Option usage of Hasher.java says:
> "    -md depth    max chain depth (default 3)"
> "    -mb bits     max index bits (lg of table size, default 10)"
> In case of setting -md to x the max chain depth properly results in x, 
> but ...
> in case of setting -mb to x the max lg of table size inproperly 
> results in x-1 bits, as you can see in -verbose output of the hasher.
>
> To ensure, that the default value is processed as it would be 10, 
> variable maxBits is pre-set to 11, to "workaround" the bug.
> When fixing this bug, any usage of this option should be corrected to 
> x-1 to ensure identical results.
>
> I don't think the different boundary behaviour of -md and -mb is done 
> by design. Maybe processing of -md has been wrong too in first time 
> and was corrected, but correction for -mb was overseen, as never used.
>
> Maybe you could have a short call to the author Mark Reynolds to 
> ensure this. Possibly he also has knowledge of other usage than in 
> genCharsetProvider.sh.
>
>> Have you checked that the OpenJDK can still be built with this change 
>> in place?
>>   
>
> I have scanned over
> - hg.openjdk.java.net/jdk7/tl/jdk/make
> - hg.openjdk.java.net/jdk7/tl/jdk/src
> - hg.openjdk.java.net/jdk7/tl/jdk/test
>
> The only usage of Hasher.java I've found in:
> - hg.openjdk.java.net/jdk7/tl/jdk/make/java/nio/genCharsetProvider.sh
>
> In this case, the option -mb  is not used. I assume, this is the 
> reason, why nobody has experienced this bug before.
>
> I have *not* scanned over
> - hg.openjdk.java.net/jdk7/tl/hotspot .../langtools etc.
> as I don't have a hg clone of them.
>
> Maybe I should have done this, but I think, it's anyway good that 
> experienced SUN engineer would do that scan too, and I guess, you have 
> better tools to do that.
>
> -Ulf
>
>



From sean.mullan at sun.com  Tue Jul 21 03:47:18 2009
From: sean.mullan at sun.com (sean.mullan at sun.com)
Date: Mon, 20 Jul 2009 20:47:18 -0700
Subject: hg: jdk7/tl/jdk: 6787645: CRL validation code should permit some
	clock skew when checking validity of CRLs
Message-ID: <20090721034750.458BEE93F@hg.openjdk.java.net>

Changeset: 1203425b5742
Author:    mullan
Date:      2009-07-20 17:16 -0400
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1203425b5742

6787645: CRL validation code should permit some clock skew when checking validity of CRLs
Reviewed-by: vinnie

! src/share/classes/java/security/cert/CertPathHelperImpl.java
! src/share/classes/java/security/cert/X509CRLSelector.java
! src/share/classes/sun/security/provider/certpath/CertPathHelper.java
! src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java
! src/share/classes/sun/security/provider/certpath/OCSPResponse.java



From ariel at weisberg.ws  Tue Jul 21 19:52:33 2009
From: ariel at weisberg.ws (Ariel Weisberg)
Date: Tue, 21 Jul 2009 15:52:33 -0400
Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
In-Reply-To: <1ccfd1c10907151424t2f835a29y80a10228e0bc66c0@mail.gmail.com>
References: <NFBBKALFDCPFIDBNKAPCAEJGICAA.davidcholmes@aapt.net.au>
	<1247540368.18990.1324916035@webmail.messagingengine.com>
	<1247685852.19957.1325194693@webmail.messagingengine.com>
	<1ccfd1c10907151424t2f835a29y80a10228e0bc66c0@mail.gmail.com>
Message-ID: <1248205953.1518.1326134111@webmail.messagingengine.com>

Hi all,

It tooks a while for me to convince ourselves that this wasn't an
application problem. I am attaching a test case that reliably
reproduces the dead socket problem on some systems. The flow is
essentially the same as the networking code in our messaging
system.

I had the best luck reproducing this on Dell Poweredge 2970s (two
socket AMD) running CentOS 5.3. I dual booted two of them with
Ubuntu server 9.04 and have not succeded in reproducing the
problem with Ubuntu. I was not able to reproduce the problem on
the Dell R610 (2 socket Nehalem) machines running CentOS 5.3 with
the test application although the actual app (messaging system)
does have this issue on the 610s.

I am very interested in hearing about what happens when other
people run it. I am also interested in confirming that this is a
sane use of Selectors, SocketChannels, and SelectionKeys.

Thanks,
Ariel Weisberg

On Wed, 15 Jul 2009 14:24 -0700, "Martin Buchholz"
<martinrb at google.com> wrote:

  In summary,
  there are two different bugs at work here,
  and neither of them is in LBD.
  The hotspot team is working on the LBD deadlock.
  (As always) It would be good to have a good test case for
  the dead socket problem.
  Martin

On Wed, Jul 15, 2009 at 12:24, Ariel Weisberg
<[1]ariel at weisberg.ws> wrote:

Hi,

I have found that there are two different failure modes without
involving -XX:+UseMembar. There is the LBD deadlock and then
there is the dead socket in between two nodes. Either failure can
occur with the same code and settings. It appears that the dead
socket problem is more common. The LBD failure is also not
correlated with any specific LBD (originally saw it with only the
LBD for an Initiator's mailbox).

With -XX:+UseMembar the system is noticeably more reliable and
tends to run much longer without failing (although it can still
fail immediately). When it does fail it has been due to a dead
connection. I have not reproduced a deadlock on an LBD with
-XX:+UseMembar.

I also found that the dead socket issue was reproducible twice on
Dell Poweredge 2970s (two socket AMD). It takes an hour or so to
reproduce the dead socket problem on the 2970. I have not
recreated the LBD issue on them although given how difficult the
socket issue is to reproduce it may be that I have not run them
long enough. On the AMD machines I did not use -XX:+UseMembar.

Ariel


On Mon, 13 Jul 2009 18:59 -0400, "Ariel Weisberg"
<[2]ariel at weisberg.ws> wrote:

Hi all.

Sorry Martin I missed reading your last email. I am not confident
that I will get a small reproducible test case in a reasonable
time frame. Reproducing it with the application is easy and I
will see what I can do about getting the source available.

One interesting thing I can tell you is that if I remove the
LinkedBlockingDeque from the mailbox of the Initiator the system
still deadlocks. The cluster has a TCP mesh topology so any node
can deliver messages to any other node. One of the connections
goes dead and neither side detects that there is a problem. I add
some assertions to the network selection thread to check that all
the connections in the cluster are still healthy and assert that
they have the correct interests set.

Here are the things it checks for  to make sure each connection
is working:
>                             for (ForeignHost.Port port :
foreignHostPorts) {
>
assert(port.m_selectionKey.isValid());
>
assert(port.m_selectionKey.selector() == m_selector);
>                             assert(port.m_channel.isOpen());
>
assert(((SocketChannel)port.m_channel).isConnected());
>
assert(((SocketChannel)port.m_channel).socket().isInputShutdown()
== false);
>
assert(((SocketChannel)port.m_channel).socket().isOutputShutdown(
) == false);
>
assert(((SocketChannel)port.m_channel).isOpen());
>
assert(((SocketChannel)port.m_channel).isRegistered());
>
assert(((SocketChannel)port.m_channel).keyFor(m_selector) !=
null);
>
assert(((SocketChannel)port.m_channel).keyFor(m_selector) ==
port.m_selectionKey);
>                             if
(m_selector.selectedKeys().contains(port.m_selectionKey)) {
>
assert((port.m_selectionKey.interestOps() & SelectionKey.OP_READ)
!= 0);
>
assert((port.m_selectionKey.interestOps() &
SelectionKey.OP_WRITE) != 0);
>                             } else {
>                                 if (port.isRunning()) {
>
assert(port.m_selectionKey.interestOps() == 0);
>                                 } else {
>
port.m_selectionKey.interestOps(SelectionKey.OP_READ |
SelectionKey.OP_WRITE);
>                                     assert((port.interestOps()
& SelectionKey.OP_READ) != 0);
>                                     assert((port.interestOps()
& SelectionKey.OP_WRITE) != 0);
>                                 }
>                             }
>                             assert(m_selector.isOpen());
>
assert(m_selector.keys().contains(port.m_selectionKey));
OP_READ | OP_WRITE is set as the interest ops every time through,
and there is no other code that changes the interest ops during
execution. The application will run for a while and then one of
the connections will stop being selected on both sides. If I step
in with the debugger on either side everything looks correct. The
keys have the correct interest ops and the selectors have the
keys in their key set.

What I suspect is happening is that a bug on one node stops the
socket from being selected (for both read and write), and
eventually the socket fills up and can't be written to by the
other side.

If I can get my VPN access together tomorrow I will run with
-XX:+UseMembar and also try running on some 8-core AMD machines.
Otherwise I will have to get to it Wednesday.

Thanks,

Ariel Weisberg


On Tue, 14 Jul 2009 05:00 +1000, "David Holmes"
<[3]davidcholmes at aapt.net.au> wrote:

Martin,



I don't think this is due to LBQ/D. This is looking similar to a
couple of other ReentrantLock/AQS "lost wakeup" hangs that I've
got on the radar. We have a reprodeucible test case for one issue
but it only fails on one kind of system - x4450. I'm on vacation
most of this week but will try and get back to this next week.



Ariel: one thing to try please see if -XX:+UseMembar fixes the
problem.



Thanks,

David Holmes

-----Original Message-----
From: Martin Buchholz [mailto:[4]martinrb at google.com]
Sent: Tuesday, 14 July 2009 8:38 AM
To: Ariel Weisberg
Cc: [5]davidcholmes at aapt.net.au; core-libs-dev;
[6]concurrency-interest at cs.oswego.edu
Subject: Re: [concurrency-interest] LinkedBlockingDeque deadlock?

  I did some stack trace eyeballing and did a mini-audit of the
  LinkedBlockingDeque code, with a view to finding possible
  bugs,
  and came up empty.  Maybe it's a deep bug in hotspot?
  Ariel, it would be good if you could get a reproducible test
  case soonish,
  while someone on the planet has the motivation and familiarity
  to fix it.
  In another month I may disavow all knowledge of
  j.u.c.*Blocking*
  Martin

On Wed, Jul 8, 2009 at 15:57, Ariel Weisberg
<[7]ariel at weisberg.ws> wrote:

  Hi,

> The poll()ing thread is blocked waiting for the internal lock,
but
> there's
> no indication of any thread owning that lock. You're using an
OpenJDK 6
> build ... can you try JDK7 ?


  I got a chance to do that today. I downloaded JDK 7 from
  [8]http://www.java.net/download/jdk7/binaries/jdk-7-ea-bin-b63
  -linux-x64-02_jul_2009.bin
  and was able to reproduce the problem. I have attached the
  stack trace
  from running the 1.7 version. It is the same situation as
  before except
  there are 9 execution sites running on each host. There are no
  threads
  that are missing or that have been restarted. Foo Network
  thread
  (selector thread) and Network Thread - 0 are waiting on
  0x00002aaab43d3b28. I also ran with JDK 7 and 6 and
  LinkedBlockingQueue
  and was not able to recreate the problem using that structure.

> I don't recall anything similar to this, but I don't know what
version
> that
> OpenJDK6 build relates to.


  The cluster is running on CentOS 5.3.
  >[aweisberg at 3f ~]$ rpm -qi
  java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5
  >Name        : java-1.6.0-openjdk           Relocations: (not
  relocatable)
  >Version     : 1.6.0.0                           Vendor:
  CentOS
  >Release     : 0.30.b09.el5                  Build Date: Tue
  07 Apr 2009 07:24:52 PM EDT
  >Install Date: Thu 11 Jun 2009 03:27:46 PM EDT      Build
  Host: [9]builder10.centos.org
  >Group       : Development/Languages         Source RPM:
  java-1.6.0-openjdk-1.6.0.0-0.30.b09.el5.src.rpm
  >Size        : 76336266                         License: GPLv2
  with exceptions
  >Signature   : DSA/SHA1, Wed 08 Apr 2009 07:55:13 AM EDT, Key
  ID a8a447dce8562897
  >URL         : [10]http://icedtea.classpath.org/
  >Summary     : OpenJDK Runtime Environment
  >Description :
  >The OpenJDK runtime environment.

> Make sure you haven't missed any exceptions occurring in other
threads.

  There are no threads missing in the application (terminated
  threads are
  not replaced) and there is a try catch pair (prints error and
  rethrows)
  around the run loop of each thread. It is possible that an
  exception may
  have been swallowed up somewhere.

>A small reproducible test case from you would be useful.

  I am working on that. I wrote a test case that mimics the
  application's
  use of the LBD, but I have not succeeded in reproducing the
  problem in
  the test case. The app has a single thread (network selector)
  that polls
  the LBD and several threads (ExecutionSites, and network
  threads that
  return results from remote ExecutionSites) that offer results
  into the
  queue. About 120k items will go into/out of the deque each
  second. In
  the actual app the problem is reproducible but inconsistent.
  If I run on
  my dual core laptop I can't reproduce it, and it is less
  likely to occur
  with a small cluster, but with 6 nodes (~560k
  transactions/sec) the
  problem will usually appear. Sometimes the cluster will run
  for several
  minutes without issue and other times it will deadlock
  immediately.
  Thanks,
  Ariel

On Wed, 08 Jul 2009 05:14 +1000, "Martin Buchholz"
<[11]martinrb at google.com> wrote:
>[+core-libs-dev]
>
>Doug Lea and I are (slowly) working on a new version of
LinkedBlockingDeque.
>I was not aware of a deadlock but can vaguely imagine how it
might happen.
>A small reproducible test case from you would be useful.
>
>Unfinished work in progress can be found here:
>[12]http://cr.openjdk.java.net/~martin/webrevs/openjdk7/Blocking
Queue/
>
>Martin


  On Wed, 08 Jul 2009 05:14 +1000, "David Holmes"

<[13]davidcholmes at aapt.net.au> wrote:
>


> Ariel,
>
> The poll()ing thread is blocked waiting for the internal lock,
but
> there's
> no indication of any thread owning that lock. You're using an
OpenJDK 6
> build ... can you try JDK7 ?
>
> I don't recall anything similar to this, but I don't know what
version
> that
> OpenJDK6 build relates to.
>
> Make sure you haven't missed any exceptions occurring in other
threads.
>
> David Holmes
>
> > -----Original Message-----
> > From: [14]concurrency-interest-bounces at cs.oswego.edu
> > [mailto:[15]concurrency-interest-bounces at cs.oswego.edu]On
Behalf Of Ariel
> > Weisberg
> > Sent: Wednesday, 8 July 2009 8:31 AM
> > To: [16]concurrency-interest at cs.oswego.edu
> > Subject: [concurrency-interest] LinkedBlockingDeque deadlock?
> >
> >
> > Hi all,
> >
> > I did a search on LinkedBlockingDeque and didn't find
anything similar
> > to what I am seeing. Attached is the stack trace from an
application
> > that is deadlocked with three threads waiting for
0x00002aaab3e91080
> > (threads "ExecutionSite: 26", "ExecutionSite:27", and
"Network
> > Selector"). The execution sites are attempting to offer
results to the
> > deque and the network thread is trying to poll for them using
the
> > non-blocking version of poll. I am seeing the network thread
never
> > return from poll (straight poll()). Do my eyes deceive me?
> >
> > Thanks,
> >
> > Ariel Weisberg
> >
>

  _______________________________________________
  Concurrency-interest mailing list
  [17]Concurrency-interest at cs.oswego.edu
  [18]http://cs.oswego.edu/mailman/listinfo/concurrency-interest

References

1. mailto:ariel at weisberg.ws
2. mailto:ariel at weisberg.ws
3. mailto:davidcholmes at aapt.net.au
4. mailto:martinrb at google.com
5. mailto:davidcholmes at aapt.net.au
6. mailto:concurrency-interest at cs.oswego.edu
7. mailto:ariel at weisberg.ws
8. http://www.java.net/download/jdk7/binaries/jdk-7-ea-bin-b63-linux-x64-02_jul_2009.bin
9. http://builder10.centos.org/
  10. http://icedtea.classpath.org/
  11. mailto:martinrb at google.com
  12. http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk7/BlockingQueue/
  13. mailto:davidcholmes at aapt.net.au
  14. mailto:concurrency-interest-bounces at cs.oswego.edu
  15. mailto:concurrency-interest-bounces at cs.oswego.edu
  16. mailto:concurrency-interest at cs.oswego.edu
  17. mailto:Concurrency-interest at cs.oswego.edu
  18. http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090721/c2f53c4a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TCPThroughput.java
Type: text/x-java
Size: 15838 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090721/c2f53c4a/TCPThroughput.java>

From weijun.wang at sun.com  Wed Jul 22 08:56:49 2009
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Wed, 22 Jul 2009 08:56:49 +0000
Subject: hg: jdk7/tl/jdk: 4 new changesets
Message-ID: <20090722085758.8DE65EB9A@hg.openjdk.java.net>

Changeset: 81e3117803a5
Author:    weijun
Date:      2009-07-22 16:39 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/81e3117803a5

6858589: more changes to Config on system properties
Reviewed-by: valeriep

! src/share/classes/sun/security/krb5/Config.java
! src/share/classes/sun/security/krb5/KrbApReq.java
! test/sun/security/krb5/ConfPlusProp.java

Changeset: 8bb89d9fd061
Author:    weijun
Date:      2009-07-22 16:40 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8bb89d9fd061

6847026: keytool should be able to generate certreq and cert without subject name
Reviewed-by: xuelei

! src/share/classes/sun/security/tools/KeyTool.java
! src/share/classes/sun/security/util/Resources.java
+ test/sun/security/tools/keytool/emptysubject.sh

Changeset: f4f55c2473b6
Author:    weijun
Date:      2009-07-22 16:40 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f4f55c2473b6

6854308: more ktab options
Reviewed-by: mullan

! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java
! src/windows/classes/sun/security/krb5/internal/tools/Klist.java
! src/windows/classes/sun/security/krb5/internal/tools/Ktab.java

Changeset: 29b076bfeafd
Author:    weijun
Date:      2009-07-22 16:41 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/29b076bfeafd

6561126: keytool should use larger default keysize for keypairs
Reviewed-by: mullan

! src/share/classes/sun/security/tools/JarSigner.java
! src/share/classes/sun/security/tools/KeyTool.java
! src/share/classes/sun/security/util/Resources.java
+ test/sun/security/tools/jarsigner/newsize7.sh
+ test/sun/security/tools/keytool/NewSize7.java



From dl at cs.oswego.edu  Wed Jul 22 16:21:35 2009
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 22 Jul 2009 12:21:35 -0400
Subject: Faster HashMap implementation
In-Reply-To: <4A4F6B75.607@univ-mlv.fr>
References: <f813797e0906031621l650feb9erd313d6a3872a2941@mail.gmail.com>	<4A2D3729.3040904@cs.oswego.edu>	<f813797e0906080959p65f04f94t170249f285e55597@mail.gmail.com>	<4A2E5109.4050804@cs.oswego.edu>	<f813797e0906090743oca8faf7he2c066b125c190ef@mail.gmail.com>	<4A40FD16.6040503@cs.oswego.edu>	<f813797e0906262054n56d251b7w5fbf4e163b565a8a@mail.gmail.com>	<4A4A8D00.8000506@cs.oswego.edu>	<f813797e0907010550v5c65c2fdvabab7575f01092b6@mail.gmail.com>	<5429.69.38.226.2.1246543750.squirrel@altair.cs.oswego.edu>	<loom.20090702T181948-756@post.gmane.org>
	<58327.89.96.170.50.1246690839.squirrel@altair.cs.oswego.edu>
	<4A4F6B75.607@univ-mlv.fr>
Message-ID: <4A673C8F.3050106@cs.oswego.edu>

Sorry for the delay getting back to this.

I put an update of HashMapV2 at
   http://gee.cs.oswego.edu/dl/wwwtmp/HashMapV2.java
It includes the better support for tiny maps and probe sequences that
were missing.

On further evaluating it (among other possible HashMap replacements),
I'm not convinced that they are enough better to commit.

To explain why, I'll first back up to the main observations that lead
to exploring open-address (unchained) tables.  Here are runs of JDK
HashMap (using chained) vs IdentityHashMap (IHM) (using open
addressing) on (further updated) MapMicroBenchmark on an x86 (this is
typical of other x86 and sparc runs).  Also shown is current
HashMapV2.  Times in nanosecs per element-operation, averaged across 8
key types.

      Size:   9     36    144    576   2304   9216  36864 147456 589824
HashMap     49     33     30     33     37     45     97    208    273
IHM         41     28     26     28     31     35     58    151    188
V2          47     31     29     37     36     40     78    188    257

On these (and other) tests, IdentityHashMap is from 15% to 60% faster
than HashMap.  Plus it typically has a smaller footprint, by around
40% in steady state (although for tiny tables it has a larger
footprint.)  So you'd think that by compromising a bit on the
properties that make IHM faster, it would be possible to arrive at
something close in revised HashMap.  HashMapV2 usually is in-between
on both time and space, but unfortunately much closer to HashMap,
close enough that it is probably no better than making a couple of
simple tweaks to the current HashMap (see below).

The main issues are hash quality and caching:

1. IdentityHashCodes have good randomness properties. (This is by
design: In hotspot, they are produced by a simple random number
generator.)  This means that basic linear-probe open-address table in
IHM usually runs close to its theoretical expected performance level.
To effectively deal with non-randomness of hashCode (vs
identityHashCodes) for common key types, you need to both precondition
(bit-spread) them, and give up on linear-probing and instead use
psuedo-randomized probing techniques.  (If you do no preconditioning
and use linear probing, you get factor of 20X slowdowns for some known
key type/value usages.)  The first costs computation overhead; the
second costs memory locality.  While you can trade these off a bit
(heavier preconditioning vs more locality of subsequent probes), I
don't know of pair of such techniques better than those in current V2.
And even these measures cannot achieve as much randomness as you get
in IdentityHashMap. In particular, neither help much when dealing with
the common problem of encountering much greater than (theorecticallY
expected numbers of duplicate hashCodes. In a chained table, these
poison only one bin, but in open-adresss they tend to reduce overall
performance. So all in all, the hit rates are noticeably worse.

2. Because Objects themselves are required to cache their own
identityHashCodes, there is no reason for IdentityHashMap to do so. So
there is no need for a side-array to hold them.  The overall space
reduction also makes it an easy call to use a 2/3 vs 3/4 load factor
threshold, which is a good/common value for open-address tables.  The
need for side-array of hashes in HashMapV2 not only takes up some
space, but also leads to cache misses, mainly on collisions. For large
tables, these cases noticeably hurt overall throughput. Note: One
reason for caching hashes is compatibility. For many key types (see
below) it is a better tradeoff to recompute them when needed for
rehashing and not to bother using them to pre-screen equals. But there
are exceptions, and people out there surely have code the relies on
lack of recomputation.

(In case anyone is curious, the best version I tried with heavy
randomizer, linear probe, and no side-array has benchmark stats:
      Size:   9     36    144    576   2304   9216  36864 147456 589824
average     46     36     38     44     43     49     88    235    294
which is OK, but without any room to improve to the point of being
good enough to invite a slew of performance bug reports about hash
recomputations.)

Further, the minor-looking compatibility issues with current HashMap
(like needing an entirely different map to handle overflow after
500million entries) all add some constant overhead.  Plus the
intrinsically worse performance on some entrySet operations because of
lack of Entry objects. Simple escape analysis will often but not
always come to the rescue here, so it is a relatively minor concern.
But all together these contribute to the conclusion that open-address
approach doesn't have enough advantages to replace HashMap. Similarly
for the mixed-side-array approach of Alex's Compact/Fast HashMap.

As I mentioned in previous posts, it is possible to use open
addressing to get speedups and footprint reductions comparable to IHM
for the set of key types that seem to account for up to 80% of all
usages: Strings, Integer/Long, and identity.  All three share lack of
need to cache hash codes plus either good randomization properties or
known cheap ways to attain them.  Identity is already supported, but
people don't seem to choose IdentityHashMaps all that often even when
they apply.  The Integer case is supported in a not-very-nice way in
Sun JDK releases under -XX:+AggressiveOpts.  Strings are by far the
most common case but no one has tried anything comparable.  Internal
specialization might be worth a try but I can't get too excited about
prospects for the only available means of doing this -- optimistic
type tests followed by costly de-optimization when you are wrong. This
extends the lack of performance predicatability you already get in
Java to living with higher-order algorithmic luckiness. Explicit
specialization (as is upcoming in Scala) seems like a much better
line of attack.

There is though one issue surrounding current HashMaps that does seem
to deserve a short-term minor improvement. People (including the IBM
"bloat" paper folks) have repeatedly shown that a great many HashMaps
are either permanently empty or hold at most a few elements. It would
be pretty straightforward to accommodate this by (1) lazily
initializing arrays (2) initially allocating only capacity 4, then
jumping to current default of 16 on first resize. This seems like a
simple win. Testing this out, it seems to have almost no performance
impact on non-tiny map usages. (In part because adding an initial
4->16 resize warms up the resize code.)

-Doug



From poonam.bajaj at sun.com  Wed Jul 22 22:06:58 2009
From: poonam.bajaj at sun.com (poonam.bajaj at sun.com)
Date: Wed, 22 Jul 2009 22:06:58 +0000
Subject: hg: jdk7/tl/jdk: 6814140: deadlock due to synchronized demandLogger()
	code that locks ServerLogManager
Message-ID: <20090722220753.470C0EC2F@hg.openjdk.java.net>

Changeset: dba7dc47b78e
Author:    poonam
Date:      2009-07-22 07:49 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dba7dc47b78e

6814140: deadlock due to synchronized demandLogger() code that locks ServerLogManager
Summary: Making demandLogger() non-synchronized resolves the deadlock.
Reviewed-by: dcubed

! src/share/classes/java/util/logging/LogManager.java



From David.Holmes at Sun.COM  Thu Jul 23 05:48:31 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Thu, 23 Jul 2009 15:48:31 +1000
Subject: [concurrency-interest] LinkedBlockingDeque deadlock? (Test case)
In-Reply-To: <NFBBKALFDCPFIDBNKAPCOEKJICAA.davidcholmes@aapt.net.au>
References: <NFBBKALFDCPFIDBNKAPCOEKJICAA.davidcholmes@aapt.net.au>
Message-ID: <4A67F9AF.7020304@sun.com>

Just an update.

The good news is that I managed to reproduce this on an 8-way Intel box. 
Sometimes it hangs due to the applications LinkedBlockingDeque and 
sometimes it hangs in the executor's LinkedBlockingQueue.

The bad news is that as soon as I modified the LBQ/LBD  and 
ReentrantLock code to allow me to probe deeper, I can no longer 
reproduce the problem :-( And all I did to the code was make everything 
public so that I could dump the lock state when the hang occurred.

Very frustrating ...

David

David Holmes said the following on 07/18/09 12:28:
> Sorry Ryan, misread the stack trace. The main thread is interacting with the
> executors LBQ not the application one.
> 
> I'll see if I can use this test to reproduce the issue on Monday.
> 
> David Holmes
> 
>> -----Original Message-----
>> From: concurrency-interest-bounces at cs.oswego.edu
>> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of David
>> Holmes
>> Sent: Saturday, 18 July 2009 12:15 PM
>> To: Ryan Betts; concurrency-interest at cs.oswego.edu
>> Cc: core-libs-dev
>> Subject: Re: [concurrency-interest] LinkedBlockingDeque deadlock? (Test
>> case)
>>
>>
>>
>>
>> Ryan,
>>
>> Thanks very much for this.
>>
>> When this "deadlocks" does top show whether the java process is actually
>> quiet or is it still consuming CPU? I notice that in the stack
>> dump the main
>> thread is in the process of unlocking the lock that the other threads are
>> waiting upon and hence the system is not deadlocked - unless that main
>> thread is actually "stuck" somewhere. Can you take a series of
>> stackdumps to
>> see if/how the main thread is executing?
>>
>> Feel free to just send them to me rather than the mailing lists.
>>
>> Thanks,
>> David Holmes
>>
>>> -----Original Message-----
>>> From: concurrency-interest-bounces at cs.oswego.edu
>>> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Ryan
>>> Betts
>>> Sent: Saturday, 18 July 2009 2:48 AM
>>> To: concurrency-interest at cs.oswego.edu
>>> Cc: core-libs-dev
>>> Subject: Re: [concurrency-interest] LinkedBlockingDeque deadlock? (Test
>>> case)
>>>
>>>
>>> Hello all,
>>>
>>> I've been working with Ariel on the j.u.c.LinkedBlockingDeque deadlock
>>> we observe. The attached test case reproduces the deadlock
>>> intermittently, usually requiring several minutes. The test simply
>>> prints periods until it deadlocks. Attempts to produce a simpler test
>>> case using only ReentrantLock or without an ExecutorService were
>>> unsuccessful.
>>>
>>> I've attached jstack reports showing the deadlocked case and the dmesg
>>> output from one of the servers that reproduces the defect. To date,
>>> this deadlock only occurs on our 2 socket i7s.
>>>
>>> We have not filed a defect with Sun for this issue. If that would be
>>> helpful (or necessary), we would of course happily oblige.
>>>
>>> $ java -version
>>> java version "1.6.0"
>>> OpenJDK  Runtime Environment (build 1.6.0-b09)
>>> OpenJDK 64-Bit Server VM (build 1.6.0-b09, mixed mode)
>>>
>>> $ uname -a
>>> Linux host3e 2.6.18-128.1.16.el5 #1 SMP Tue Jun 30 06:07:26 EDT 2009
>>> x86_64 x86_64 x86_64 GNU/Linux
>>>
>>> $ javac LBDLockPatternTest.java
>>> $ java LBDLockPatternTest
>>>
>>>
>>> Thank you,
>>> *--Ryan.
>>>
>>>
>>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 


From christopher.hegarty at sun.com  Thu Jul 23 13:12:55 2009
From: christopher.hegarty at sun.com (christopher.hegarty at sun.com)
Date: Thu, 23 Jul 2009 13:12:55 +0000
Subject: hg: jdk7/tl/jdk: 6863110: Newly connected/accepted SctpChannel should
	fire OP_READ if registered with a Selector
Message-ID: <20090723131344.7151CECB4@hg.openjdk.java.net>

Changeset: 645c1d0b9db9
Author:    chegar
Date:      2009-07-23 14:06 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/645c1d0b9db9

6863110: Newly connected/accepted SctpChannel should fire OP_READ if registered with a Selector
Reviewed-by: jccollet

! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java
! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java
! src/solaris/native/sun/nio/ch/SctpChannelImpl.c
+ test/com/sun/nio/sctp/SctpChannel/CommUp.java
! test/com/sun/nio/sctp/SctpMultiChannel/Branch.java
! test/com/sun/nio/sctp/SctpMultiChannel/SocketOptionTests.java



From jonathan.gibbons at sun.com  Thu Jul 23 18:46:34 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 23 Jul 2009 18:46:34 +0000
Subject: hg: jdk7/tl/langtools: 6863814: javap crashes when facing array class
	literals
Message-ID: <20090723184640.51977EED8@hg.openjdk.java.net>

Changeset: 99b7a25185aa
Author:    jjg
Date:      2009-07-23 11:37 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/99b7a25185aa

6863814: javap crashes when facing array class literals
Reviewed-by: jjg
Contributed-by: mali at csail.mit.edu

! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java
+ test/tools/javap/typeAnnotations/ArrayClassLiterals.java



From yu-ching.peng at sun.com  Thu Jul 23 19:48:47 2009
From: yu-ching.peng at sun.com (yu-ching.peng at sun.com)
Date: Thu, 23 Jul 2009 19:48:47 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20090723194928.768C4EEE8@hg.openjdk.java.net>

Changeset: cd7758c85d13
Author:    valeriep
Date:      2009-07-22 17:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cd7758c85d13

6823905: crash in sun.security.pkcs11.wrapper.PKCS11.C_Sign during stress-test
Summary: Initialize relevant return value to NULL
Reviewed-by: vinnie

! src/share/native/sun/security/pkcs11/wrapper/p11_general.c
! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c
! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c
! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c
! src/share/native/sun/security/pkcs11/wrapper/p11_util.c
! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h

Changeset: 4b287af811ba
Author:    valeriep
Date:      2009-07-23 12:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4b287af811ba

Merge




From jonathan.gibbons at sun.com  Thu Jul 23 21:23:18 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 23 Jul 2009 21:23:18 +0000
Subject: hg: jdk7/tl/langtools: 6863914: bug number missing from test
Message-ID: <20090723212322.81B58EEF3@hg.openjdk.java.net>

Changeset: 49387c1440d0
Author:    jjg
Date:      2009-07-23 14:15 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/49387c1440d0

6863914: bug number missing from test
Reviewed-by: tbell

! test/tools/javap/typeAnnotations/ArrayClassLiterals.java



From Mandy.Chung at Sun.COM  Thu Jul 23 23:53:58 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Thu, 23 Jul 2009 16:53:58 -0700
Subject: Review request for 4917309 and 6864003
Message-ID: <4A68F816.3060002@Sun.com>

This review request is for both the HotSpot runtime and the core libs teams.

Fixed 4917309: (cl) Reduce internal usage of ClassNotFoundExceptions during 
class-loading
Fixed 6864003: Modify JVM_FindClassFromBootLoader to return null if class 
not found

Summary:
  o Fix java.lang.ClassLoader to use the new VM entry point
    JVM_FindClassFromBootLoader for load a system class from
    the bootstrap classloader that will reduce the number
    of ClassNotFoundException objects thrown by the application
    class loader by 50%.  The remaining half of the ClassNotFoundException
    objects are thrown by the extension class loader which is the parent
    of the application class loader.
  o ClassLoader.loadClass and ClassLoader.findSystemClass will
    throw ClassNotFoundException as they are specified.
  o JVM_FindClassFromBootLoader is currently not used (going to
    used by the java launcher see 6864028). There is no issue
    of changing it to return null instead of throwing CNFE.

Webrev:
   http://cr.openjdk.java.net/~mchung/4917309/hotspot-webrev/
   http://cr.openjdk.java.net/~mchung/4917309/jdk-webrev/


Thanks
Mandy





From David.Holmes at Sun.COM  Fri Jul 24 03:17:05 2009
From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems)
Date: Fri, 24 Jul 2009 13:17:05 +1000
Subject: Review request for 4917309 and 6864003
In-Reply-To: <4A68F816.3060002@Sun.com>
References: <4A68F816.3060002@Sun.com>
Message-ID: <4A6927B1.5090403@sun.com>

Hi Mandy,

  661 JVM_ENTRY(jclass, JVM_FindClassFromBootLoader(JNIEnv* env,
  662                                               const char* name,
  663                                               jboolean throwError))

Can't we now drop the throwError parameter altogether?

Pity we can't make a similar fix to the extensions loader ...

Cheers,
David

Mandy Chung said the following on 07/24/09 09:53:
> This review request is for both the HotSpot runtime and the core libs 
> teams.
> 
> Fixed 4917309: (cl) Reduce internal usage of ClassNotFoundExceptions 
> during class-loading
> Fixed 6864003: Modify JVM_FindClassFromBootLoader to return null if 
> class not found
> 
> Summary:
>  o Fix java.lang.ClassLoader to use the new VM entry point
>    JVM_FindClassFromBootLoader for load a system class from
>    the bootstrap classloader that will reduce the number
>    of ClassNotFoundException objects thrown by the application
>    class loader by 50%.  The remaining half of the ClassNotFoundException
>    objects are thrown by the extension class loader which is the parent
>    of the application class loader.
>  o ClassLoader.loadClass and ClassLoader.findSystemClass will
>    throw ClassNotFoundException as they are specified.
>  o JVM_FindClassFromBootLoader is currently not used (going to
>    used by the java launcher see 6864028). There is no issue
>    of changing it to return null instead of throwing CNFE.
> 
> Webrev:
>   http://cr.openjdk.java.net/~mchung/4917309/hotspot-webrev/
>   http://cr.openjdk.java.net/~mchung/4917309/jdk-webrev/
> 
> 
> Thanks
> Mandy
> 
> 
> 


From Mandy.Chung at Sun.COM  Fri Jul 24 05:29:07 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Thu, 23 Jul 2009 22:29:07 -0700
Subject: Review request for 4917309 and 6864003
In-Reply-To: <4A6927B1.5090403@sun.com>
References: <4A68F816.3060002@Sun.com> <4A6927B1.5090403@sun.com>
Message-ID: <4A6946A3.6030703@sun.com>

David Holmes - Sun Microsystems wrote:
> Hi Mandy,
>
>  661 JVM_ENTRY(jclass, JVM_FindClassFromBootLoader(JNIEnv* env,
>  662                                               const char* name,
>  663                                               jboolean throwError))
>
> Can't we now drop the throwError parameter altogether?
>
Yes, I could.  I agree it doesn't need this throwError parameter.   I 
decide to leave it since it helps to avoid the synchronized pushes.  
JVM_FindClassFromBootLoader is already in a promoted build.   I can push 
the JDK fix and HotSpot fix at the same time.  Note that the JDK fix and 
HotSpot fix are pushed and integrated in two different gates and at 
different time.

If I modify the signature, I would have to push the HS fix first (say 
b68).  Wait until b68 is promoted, then I can push the JDK fix in b70.

If you strongly feel that I should drop the throwError parameter, I 
could make the change.

Thanks
Mandy
 
> Pity we can't make a similar fix to the extensions loader ...
>
> Cheers,
> David
>
> Mandy Chung said the following on 07/24/09 09:53:
>> This review request is for both the HotSpot runtime and the core libs 
>> teams.
>>
>> Fixed 4917309: (cl) Reduce internal usage of ClassNotFoundExceptions 
>> during class-loading
>> Fixed 6864003: Modify JVM_FindClassFromBootLoader to return null if 
>> class not found
>>
>> Summary:
>>  o Fix java.lang.ClassLoader to use the new VM entry point
>>    JVM_FindClassFromBootLoader for load a system class from
>>    the bootstrap classloader that will reduce the number
>>    of ClassNotFoundException objects thrown by the application
>>    class loader by 50%.  The remaining half of the 
>> ClassNotFoundException
>>    objects are thrown by the extension class loader which is the parent
>>    of the application class loader.
>>  o ClassLoader.loadClass and ClassLoader.findSystemClass will
>>    throw ClassNotFoundException as they are specified.
>>  o JVM_FindClassFromBootLoader is currently not used (going to
>>    used by the java launcher see 6864028). There is no issue
>>    of changing it to return null instead of throwing CNFE.
>>
>> Webrev:
>>   http://cr.openjdk.java.net/~mchung/4917309/hotspot-webrev/
>>   http://cr.openjdk.java.net/~mchung/4917309/jdk-webrev/
>>
>>
>> Thanks
>> Mandy
>>
>>
>>



From Ulf.Zibis at gmx.de  Fri Jul 24 05:46:06 2009
From: Ulf.Zibis at gmx.de (Ulf Zibis)
Date: Fri, 24 Jul 2009 07:46:06 +0200
Subject: Review/sponsor request: 6850361 Avoid 2-step lookup in sun.nio.cs
	charset providers 
Message-ID: <4A694A9E.2010201@gmx.de>

Martin, Sherman, Dalibor,

do you like to review and/or sponsor my CR ?

This fix would additionally speed-up the lookup of charsets and save some memory.
The footprint of the code is again little smaller than before.

See:
https://bugs.openjdk.java.net/show_bug.cgi?id=100095

Thanks,

Ulf









From mlists at juma.me.uk  Fri Jul 24 11:14:00 2009
From: mlists at juma.me.uk (Ismael Juma)
Date: Fri, 24 Jul 2009 11:14:00 +0000 (UTC)
Subject: Faster HashMap implementation
References: <f813797e0906031621l650feb9erd313d6a3872a2941@mail.gmail.com>	<4A2D3729.3040904@cs.oswego.edu>	<f813797e0906080959p65f04f94t170249f285e55597@mail.gmail.com>	<4A2E5109.4050804@cs.oswego.edu>	<f813797e0906090743oca8faf7he2c066b125c190ef@mail.gmail.com>	<4A40FD16.6040503@cs.oswego.edu>	<f813797e0906262054n56d251b7w5fbf4e163b565a8a@mail.gmail.com>	<4A4A8D00.8000506@cs.oswego.edu>	<f813797e0907010550v5c65c2fdvabab7575f01092b6@mail.gmail.com>	<5429.69.38.226.2.1246543750.squirrel@altair.cs.oswego.edu>	<loom.20090702T181948-756@post.gmane.org>
	<58327.89.96.170.50.1246690839.squirrel@altair.cs.oswego.edu>
	<4A4F6B75.607@univ-mlv.fr> <4A673C8F.3050106@cs.oswego.edu>
Message-ID: <loom.20090724T110455-669@post.gmane.org>

Hi Doug,

Doug Lea <dl at ...> writes:
> On further evaluating it (among other possible HashMap replacements),
> I'm not convinced that they are enough better to commit.

That's a shame. What about that idea of having a factory method that would take
a Class object and return an appropriate Map implementation based on that? I
think this would be used more than IdentityHashMap as users could be instructed
to use that factory method all the time (unless they had a good reason not to)
instead of having to exercise judgement (like they have to do with
IdentityHashMap). One could even add a detector to findBugs (like it has for
Integer.valueOf and similar).

Best,
Ismael



From Alan.Bateman at Sun.COM  Fri Jul 24 11:54:54 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 24 Jul 2009 12:54:54 +0100
Subject: Review request for 4917309 and 6864003
In-Reply-To: <4A6946A3.6030703@sun.com>
References: <4A68F816.3060002@Sun.com> <4A6927B1.5090403@sun.com>
	<4A6946A3.6030703@sun.com>
Message-ID: <4A69A10E.6010800@sun.com>

Mandy Chung wrote:
> David Holmes - Sun Microsystems wrote:
>> Hi Mandy,
>>
>>  661 JVM_ENTRY(jclass, JVM_FindClassFromBootLoader(JNIEnv* env,
>>  662                                               const char* name,
>>  663                                               jboolean throwError))
>>
>> Can't we now drop the throwError parameter altogether?
>>
> Yes, I could.  I agree it doesn't need this throwError parameter.   I 
> decide to leave it since it helps to avoid the synchronized pushes.  
> JVM_FindClassFromBootLoader is already in a promoted build.   I can 
> push the JDK fix and HotSpot fix at the same time.  Note that the JDK 
> fix and HotSpot fix are pushed and integrated in two different gates 
> and at different time.
>
> If I modify the signature, I would have to push the HS fix first (say 
> b68).  Wait until b68 is promoted, then I can push the JDK fix in b70.
>
> If you strongly feel that I should drop the throwError parameter, I 
> could make the change.
Mandy,

I see in ClassLoader#loadClass that you still allow 
findBootstrapClassOrNull to throw CNF. I assume this is needed until 
there is a promoted build with the updated JVM_FindClassFromBootLoader, 
after which you will go back to clean it up - do I have this right? If 
so, they perhaps this helps with the justification to do this in two 
phases and eliminate throwError before any code can call it.

Otherwise, good work. I hope the reduction in CNF exceptions will make a 
measurable difference.

-Alan.


From Keith.McGuigan at Sun.COM  Fri Jul 24 13:23:07 2009
From: Keith.McGuigan at Sun.COM (Keith McGuigan)
Date: Fri, 24 Jul 2009 09:23:07 -0400
Subject: Review request for 4917309 and 6864003
In-Reply-To: <4A6946A3.6030703@sun.com>
References: <4A68F816.3060002@Sun.com> <4A6927B1.5090403@sun.com>
	<4A6946A3.6030703@sun.com>
Message-ID: <4A69B5BB.6000505@sun.com>


I would prefer that we avoid requiring synchronous pushes (so I guess I 
think we should leave that parameter in for now).

If anything, maybe file a low-priority RFE to remove that parameter later?

--
- Keith

Mandy Chung wrote:
> David Holmes - Sun Microsystems wrote:
>> Hi Mandy,
>>
>>  661 JVM_ENTRY(jclass, JVM_FindClassFromBootLoader(JNIEnv* env,
>>  662                                               const char* name,
>>  663                                               jboolean throwError))
>>
>> Can't we now drop the throwError parameter altogether?
>>
> Yes, I could.  I agree it doesn't need this throwError parameter.   I 
> decide to leave it since it helps to avoid the synchronized pushes.  
> JVM_FindClassFromBootLoader is already in a promoted build.   I can push 
> the JDK fix and HotSpot fix at the same time.  Note that the JDK fix and 
> HotSpot fix are pushed and integrated in two different gates and at 
> different time.
> 
> If I modify the signature, I would have to push the HS fix first (say 
> b68).  Wait until b68 is promoted, then I can push the JDK fix in b70.
> 
> If you strongly feel that I should drop the throwError parameter, I 
> could make the change.
> 
> Thanks
> Mandy
> 
>> Pity we can't make a similar fix to the extensions loader ...
>>
>> Cheers,
>> David
>>
>> Mandy Chung said the following on 07/24/09 09:53:
>>> This review request is for both the HotSpot runtime and the core libs 
>>> teams.
>>>
>>> Fixed 4917309: (cl) Reduce internal usage of ClassNotFoundExceptions 
>>> during class-loading
>>> Fixed 6864003: Modify JVM_FindClassFromBootLoader to return null if 
>>> class not found
>>>
>>> Summary:
>>>  o Fix java.lang.ClassLoader to use the new VM entry point
>>>    JVM_FindClassFromBootLoader for load a system class from
>>>    the bootstrap classloader that will reduce the number
>>>    of ClassNotFoundException objects thrown by the application
>>>    class loader by 50%.  The remaining half of the 
>>> ClassNotFoundException
>>>    objects are thrown by the extension class loader which is the parent
>>>    of the application class loader.
>>>  o ClassLoader.loadClass and ClassLoader.findSystemClass will
>>>    throw ClassNotFoundException as they are specified.
>>>  o JVM_FindClassFromBootLoader is currently not used (going to
>>>    used by the java launcher see 6864028). There is no issue
>>>    of changing it to return null instead of throwing CNFE.
>>>
>>> Webrev:
>>>   http://cr.openjdk.java.net/~mchung/4917309/hotspot-webrev/
>>>   http://cr.openjdk.java.net/~mchung/4917309/jdk-webrev/
>>>
>>>
>>> Thanks
>>> Mandy
>>>
>>>
>>>
> 



From Paul.Hohensee at Sun.COM  Fri Jul 24 15:07:14 2009
From: Paul.Hohensee at Sun.COM (Paul Hohensee)
Date: Fri, 24 Jul 2009 11:07:14 -0400
Subject: Review request for 4917309 and 6864003
In-Reply-To: <4A69B5BB.6000505@sun.com>
References: <4A68F816.3060002@Sun.com> <4A6927B1.5090403@sun.com>
	<4A6946A3.6030703@sun.com> <4A69B5BB.6000505@sun.com>
Message-ID: <4A69CE22.7090500@sun.com>

Can't remove it unless it's fixed in jdk6 as well as 7.  Also, one of 
these days we'll
get around to shipping current hotspot in jdk5 and maybe 1.4.2.  How 
would these
be affected?

paul

Keith McGuigan wrote:
>
> I would prefer that we avoid requiring synchronous pushes (so I guess 
> I think we should leave that parameter in for now).
>
> If anything, maybe file a low-priority RFE to remove that parameter 
> later?
>
> -- 
> - Keith
>
> Mandy Chung wrote:
>> David Holmes - Sun Microsystems wrote:
>>> Hi Mandy,
>>>
>>>  661 JVM_ENTRY(jclass, JVM_FindClassFromBootLoader(JNIEnv* env,
>>>  662                                               const char* name,
>>>  663                                               jboolean 
>>> throwError))
>>>
>>> Can't we now drop the throwError parameter altogether?
>>>
>> Yes, I could.  I agree it doesn't need this throwError parameter.   I 
>> decide to leave it since it helps to avoid the synchronized pushes.  
>> JVM_FindClassFromBootLoader is already in a promoted build.   I can 
>> push the JDK fix and HotSpot fix at the same time.  Note that the JDK 
>> fix and HotSpot fix are pushed and integrated in two different gates 
>> and at different time.
>>
>> If I modify the signature, I would have to push the HS fix first (say 
>> b68).  Wait until b68 is promoted, then I can push the JDK fix in b70.
>>
>> If you strongly feel that I should drop the throwError parameter, I 
>> could make the change.
>>
>> Thanks
>> Mandy
>>
>>> Pity we can't make a similar fix to the extensions loader ...
>>>
>>> Cheers,
>>> David
>>>
>>> Mandy Chung said the following on 07/24/09 09:53:
>>>> This review request is for both the HotSpot runtime and the core 
>>>> libs teams.
>>>>
>>>> Fixed 4917309: (cl) Reduce internal usage of 
>>>> ClassNotFoundExceptions during class-loading
>>>> Fixed 6864003: Modify JVM_FindClassFromBootLoader to return null if 
>>>> class not found
>>>>
>>>> Summary:
>>>>  o Fix java.lang.ClassLoader to use the new VM entry point
>>>>    JVM_FindClassFromBootLoader for load a system class from
>>>>    the bootstrap classloader that will reduce the number
>>>>    of ClassNotFoundException objects thrown by the application
>>>>    class loader by 50%.  The remaining half of the 
>>>> ClassNotFoundException
>>>>    objects are thrown by the extension class loader which is the 
>>>> parent
>>>>    of the application class loader.
>>>>  o ClassLoader.loadClass and ClassLoader.findSystemClass will
>>>>    throw ClassNotFoundException as they are specified.
>>>>  o JVM_FindClassFromBootLoader is currently not used (going to
>>>>    used by the java launcher see 6864028). There is no issue
>>>>    of changing it to return null instead of throwing CNFE.
>>>>
>>>> Webrev:
>>>>   http://cr.openjdk.java.net/~mchung/4917309/hotspot-webrev/
>>>>   http://cr.openjdk.java.net/~mchung/4917309/jdk-webrev/
>>>>
>>>>
>>>> Thanks
>>>> Mandy
>>>>
>>>>
>>>>
>>
>


From Karen.Kinnear at Sun.COM  Fri Jul 24 15:27:48 2009
From: Karen.Kinnear at Sun.COM (Karen Kinnear)
Date: Fri, 24 Jul 2009 11:27:48 -0400
Subject: Review request for 4917309 and 6864003
In-Reply-To: <4A69CE22.7090500@sun.com>
References: <4A68F816.3060002@Sun.com> <4A6927B1.5090403@sun.com>
	<4A6946A3.6030703@sun.com> <4A69B5BB.6000505@sun.com>
	<4A69CE22.7090500@sun.com>
Message-ID: <8AD98A18-3308-4C98-B729-554D8EFBFF37@sun.com>

JVM_FindClassFromBootLoader is new with JDK7. Kumar added it.

thanks,
Karen

On Jul 24, 2009, at 11:07 AM, Paul Hohensee wrote:

> Can't remove it unless it's fixed in jdk6 as well as 7.  Also, one  
> of these days we'll
> get around to shipping current hotspot in jdk5 and maybe 1.4.2.  How  
> would these
> be affected?
>
> paul
>
> Keith McGuigan wrote:
>>
>> I would prefer that we avoid requiring synchronous pushes (so I  
>> guess I think we should leave that parameter in for now).
>>
>> If anything, maybe file a low-priority RFE to remove that parameter  
>> later?
>>
>> -- 
>> - Keith
>>
>> Mandy Chung wrote:
>>> David Holmes - Sun Microsystems wrote:
>>>> Hi Mandy,
>>>>
>>>> 661 JVM_ENTRY(jclass, JVM_FindClassFromBootLoader(JNIEnv* env,
>>>> 662                                               const char* name,
>>>> 663                                               jboolean  
>>>> throwError))
>>>>
>>>> Can't we now drop the throwError parameter altogether?
>>>>
>>> Yes, I could.  I agree it doesn't need this throwError  
>>> parameter.   I decide to leave it since it helps to avoid the  
>>> synchronized pushes.  JVM_FindClassFromBootLoader is already in a  
>>> promoted build.   I can push the JDK fix and HotSpot fix at the  
>>> same time.  Note that the JDK fix and HotSpot fix are pushed and  
>>> integrated in two different gates and at different time.
>>>
>>> If I modify the signature, I would have to push the HS fix first  
>>> (say b68).  Wait until b68 is promoted, then I can push the JDK  
>>> fix in b70.
>>>
>>> If you strongly feel that I should drop the throwError parameter,  
>>> I could make the change.
>>>
>>> Thanks
>>> Mandy
>>>
>>>> Pity we can't make a similar fix to the extensions loader ...
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>> Mandy Chung said the following on 07/24/09 09:53:
>>>>> This review request is for both the HotSpot runtime and the core  
>>>>> libs teams.
>>>>>
>>>>> Fixed 4917309: (cl) Reduce internal usage of  
>>>>> ClassNotFoundExceptions during class-loading
>>>>> Fixed 6864003: Modify JVM_FindClassFromBootLoader to return null  
>>>>> if class not found
>>>>>
>>>>> Summary:
>>>>> o Fix java.lang.ClassLoader to use the new VM entry point
>>>>>   JVM_FindClassFromBootLoader for load a system class from
>>>>>   the bootstrap classloader that will reduce the number
>>>>>   of ClassNotFoundException objects thrown by the application
>>>>>   class loader by 50%.  The remaining half of the  
>>>>> ClassNotFoundException
>>>>>   objects are thrown by the extension class loader which is the  
>>>>> parent
>>>>>   of the application class loader.
>>>>> o ClassLoader.loadClass and ClassLoader.findSystemClass will
>>>>>   throw ClassNotFoundException as they are specified.
>>>>> o JVM_FindClassFromBootLoader is currently not used (going to
>>>>>   used by the java launcher see 6864028). There is no issue
>>>>>   of changing it to return null instead of throwing CNFE.
>>>>>
>>>>> Webrev:
>>>>>  http://cr.openjdk.java.net/~mchung/4917309/hotspot-webrev/
>>>>>  http://cr.openjdk.java.net/~mchung/4917309/jdk-webrev/
>>>>>
>>>>>
>>>>> Thanks
>>>>> Mandy
>>>>>
>>>>>
>>>>>
>>>
>>



From Paul.Hohensee at Sun.COM  Fri Jul 24 15:36:20 2009
From: Paul.Hohensee at Sun.COM (Paul Hohensee)
Date: Fri, 24 Jul 2009 11:36:20 -0400
Subject: Review request for 4917309 and 6864003
In-Reply-To: <8AD98A18-3308-4C98-B729-554D8EFBFF37@sun.com>
References: <4A68F816.3060002@Sun.com> <4A6927B1.5090403@sun.com>
	<4A6946A3.6030703@sun.com> <4A69B5BB.6000505@sun.com>
	<4A69CE22.7090500@sun.com>
	<8AD98A18-3308-4C98-B729-554D8EFBFF37@sun.com>
Message-ID: <4A69D4F4.9000103@sun.com>

Then just ignore what I said. :)

Paul

Karen Kinnear wrote:
> JVM_FindClassFromBootLoader is new with JDK7. Kumar added it.
>
> thanks,
> Karen
>
> On Jul 24, 2009, at 11:07 AM, Paul Hohensee wrote:
>
>> Can't remove it unless it's fixed in jdk6 as well as 7.  Also, one of 
>> these days we'll
>> get around to shipping current hotspot in jdk5 and maybe 1.4.2.  How 
>> would these
>> be affected?
>>
>> paul
>>
>> Keith McGuigan wrote:
>>>
>>> I would prefer that we avoid requiring synchronous pushes (so I 
>>> guess I think we should leave that parameter in for now).
>>>
>>> If anything, maybe file a low-priority RFE to remove that parameter 
>>> later?
>>>
>>> -- 
>>> - Keith
>>>
>>> Mandy Chung wrote:
>>>> David Holmes - Sun Microsystems wrote:
>>>>> Hi Mandy,
>>>>>
>>>>> 661 JVM_ENTRY(jclass, JVM_FindClassFromBootLoader(JNIEnv* env,
>>>>> 662                                               const char* name,
>>>>> 663                                               jboolean 
>>>>> throwError))
>>>>>
>>>>> Can't we now drop the throwError parameter altogether?
>>>>>
>>>> Yes, I could.  I agree it doesn't need this throwError parameter.   
>>>> I decide to leave it since it helps to avoid the synchronized 
>>>> pushes.  JVM_FindClassFromBootLoader is already in a promoted 
>>>> build.   I can push the JDK fix and HotSpot fix at the same time.  
>>>> Note that the JDK fix and HotSpot fix are pushed and integrated in 
>>>> two different gates and at different time.
>>>>
>>>> If I modify the signature, I would have to push the HS fix first 
>>>> (say b68).  Wait until b68 is promoted, then I can push the JDK fix 
>>>> in b70.
>>>>
>>>> If you strongly feel that I should drop the throwError parameter, I 
>>>> could make the change.
>>>>
>>>> Thanks
>>>> Mandy
>>>>
>>>>> Pity we can't make a similar fix to the extensions loader ...
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>> Mandy Chung said the following on 07/24/09 09:53:
>>>>>> This review request is for both the HotSpot runtime and the core 
>>>>>> libs teams.
>>>>>>
>>>>>> Fixed 4917309: (cl) Reduce internal usage of 
>>>>>> ClassNotFoundExceptions during class-loading
>>>>>> Fixed 6864003: Modify JVM_FindClassFromBootLoader to return null 
>>>>>> if class not found
>>>>>>
>>>>>> Summary:
>>>>>> o Fix java.lang.ClassLoader to use the new VM entry point
>>>>>>   JVM_FindClassFromBootLoader for load a system class from
>>>>>>   the bootstrap classloader that will reduce the number
>>>>>>   of ClassNotFoundException objects thrown by the application
>>>>>>   class loader by 50%.  The remaining half of the 
>>>>>> ClassNotFoundException
>>>>>>   objects are thrown by the extension class loader which is the 
>>>>>> parent
>>>>>>   of the application class loader.
>>>>>> o ClassLoader.loadClass and ClassLoader.findSystemClass will
>>>>>>   throw ClassNotFoundException as they are specified.
>>>>>> o JVM_FindClassFromBootLoader is currently not used (going to
>>>>>>   used by the java launcher see 6864028). There is no issue
>>>>>>   of changing it to return null instead of throwing CNFE.
>>>>>>
>>>>>> Webrev:
>>>>>>  http://cr.openjdk.java.net/~mchung/4917309/hotspot-webrev/
>>>>>>  http://cr.openjdk.java.net/~mchung/4917309/jdk-webrev/
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Mandy
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>


From Alan.Bateman at Sun.COM  Fri Jul 24 15:56:35 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 24 Jul 2009 16:56:35 +0100
Subject: Review request for 4917309 and 6864003
In-Reply-To: <4A69CE22.7090500@sun.com>
References: <4A68F816.3060002@Sun.com> <4A6927B1.5090403@sun.com>
	<4A6946A3.6030703@sun.com> <4A69B5BB.6000505@sun.com>
	<4A69CE22.7090500@sun.com>
Message-ID: <4A69D9B3.8060504@sun.com>

Paul Hohensee wrote:
> Can't remove it unless it's fixed in jdk6 as well as 7.  Also, one of 
> these days we'll
> get around to shipping current hotspot in jdk5 and maybe 1.4.2.  How 
> would these
> be affected?
>
> paul
I don't think it is used as it's not in the jdk's jvm.h yet. I checked 
jdk6 this morning in case it was being used there but it doesn't appear 
to be. I think the simplest way to get this parameter removed is to do 
the hotspot changes now and wait until it's in a promoted build before 
pushing the jdk changes. Doing it later, as Keith suggested, would 
require a polka lasting several builds.

-Alan.


From Mandy.Chung at Sun.COM  Fri Jul 24 16:08:27 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Fri, 24 Jul 2009 09:08:27 -0700
Subject: Review request for 4917309 and 6864003
In-Reply-To: <4A69A10E.6010800@sun.com>
References: <4A68F816.3060002@Sun.com> <4A6927B1.5090403@sun.com>
	<4A6946A3.6030703@sun.com> <4A69A10E.6010800@sun.com>
Message-ID: <4A69DC7B.4080903@sun.com>

Alan Bateman wrote:
> Mandy,
>
> I see in ClassLoader#loadClass that you still allow 
> findBootstrapClassOrNull to throw CNF. I assume this is needed until 
> there is a promoted build with the updated 
> JVM_FindClassFromBootLoader, after which you will go back to clean it 
> up - do I have this right? 
I leave the call to findBootstrapClassOrNull inside try-catch clause (1) 
to work with the existing VM and (2) I think it's better to leave it 
this way as opposed to do something like this:
   if (parent == null) { 
         c = findBootstrapClassOrNull(name);
   } else {
         try {
             c = parent.loadClass(name, false);
         } catch (ClassNotFoundException e) {
            // ClassNotFoundException thrown if class not found
            // from the non-null parent class loader
         }
    }

So that's the final version and no need to clean up.

Mandy




From Mandy.Chung at Sun.COM  Fri Jul 24 16:12:02 2009
From: Mandy.Chung at Sun.COM (Mandy Chung)
Date: Fri, 24 Jul 2009 09:12:02 -0700
Subject: Review request for 4917309 and 6864003
In-Reply-To: <4A69D9B3.8060504@sun.com>
References: <4A68F816.3060002@Sun.com> <4A6927B1.5090403@sun.com>
	<4A6946A3.6030703@sun.com> <4A69B5BB.6000505@sun.com>
	<4A69CE22.7090500@sun.com> <4A69D9B3.8060504@sun.com>
Message-ID: <4A69DD52.5020702@sun.com>

Thanks everyone.  I like clean code as well.  Since it's a new entry 
point and launcher hasn't used it yet, it is the best chance to clean 
this up.   I will eliminate the throwError parameter and do the 
synchronized integration.

Caveat: I have to double check if FX launcher is using this entry 
point.  I don't think per my conversation with Kumar.  But better to 
confirm.

The HS fix will go in b68 and the JDK fix will go in b70.

Thanks
Mandy

Alan Bateman wrote:
> Paul Hohensee wrote:
>> Can't remove it unless it's fixed in jdk6 as well as 7.  Also, one of 
>> these days we'll
>> get around to shipping current hotspot in jdk5 and maybe 1.4.2.  How 
>> would these
>> be affected?
>>
>> paul
> I don't think it is used as it's not in the jdk's jvm.h yet. I checked 
> jdk6 this morning in case it was being used there but it doesn't 
> appear to be. I think the simplest way to get this parameter removed 
> is to do the hotspot changes now and wait until it's in a promoted 
> build before pushing the jdk changes. Doing it later, as Keith 
> suggested, would require a polka lasting several builds.
>
> -Alan.



From jonathan.gibbons at sun.com  Fri Jul 24 21:56:55 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Fri, 24 Jul 2009 21:56:55 +0000
Subject: hg: jdk7/tl/langtools: 6863746: javap should not scan ct.sym by
	default
Message-ID: <20090724215702.44502E587@hg.openjdk.java.net>

Changeset: 631425840408
Author:    jjg
Date:      2009-07-24 14:47 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/631425840408

6863746: javap should not scan ct.sym by default
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javap/JavapFileManager.java
! src/share/classes/com/sun/tools/javap/JavapTask.java
! src/share/classes/com/sun/tools/javap/Options.java
+ test/tools/javap/T6863746.java



From alex14n at gmail.com  Sat Jul 25 00:04:54 2009
From: alex14n at gmail.com (Alex Yakovlev)
Date: Sat, 25 Jul 2009 04:04:54 +0400
Subject: Faster HashMap implementation
In-Reply-To: <4A673C8F.3050106@cs.oswego.edu>
References: <f813797e0906031621l650feb9erd313d6a3872a2941@mail.gmail.com>
	<4A40FD16.6040503@cs.oswego.edu>
	<f813797e0906262054n56d251b7w5fbf4e163b565a8a@mail.gmail.com>
	<4A4A8D00.8000506@cs.oswego.edu>
	<f813797e0907010550v5c65c2fdvabab7575f01092b6@mail.gmail.com>
	<5429.69.38.226.2.1246543750.squirrel@altair.cs.oswego.edu>
	<loom.20090702T181948-756@post.gmane.org>
	<58327.89.96.170.50.1246690839.squirrel@altair.cs.oswego.edu>
	<4A4F6B75.607@univ-mlv.fr> <4A673C8F.3050106@cs.oswego.edu>
Message-ID: <f813797e0907241704o6482ed1ay69eee9e1d35010c9@mail.gmail.com>

Doug,

On Wed, Jul 22, 2009 at 8:21 PM, Doug Lea<dl at cs.oswego.edu> wrote:

> On further evaluating it (among other possible HashMap replacements),
> I'm not convinced that they are enough better to commit.

> Size:    ...  9216  36864 147456 589824
> HashMap  ...    45     97    208    273
> V2       ...    40     78    188    257
Gain             +12%   +24%   +11%    +6%

More than 10% average improvement on big maps,
not worse on tiny maps, less memory usage - not a bad result imho

> Similarly for the mixed-side-array approach of Alex's Compact/Fast HashMap.

My version is a chained map, not an open map,
So concerns about locality and hit rates does not apply.
And with defragmentation there is not so many cache misses on collisions.

Alex


From martinrb at google.com  Sat Jul 25 01:31:37 2009
From: martinrb at google.com (martinrb at google.com)
Date: Sat, 25 Jul 2009 01:31:37 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20090725013344.7A580E5EE@hg.openjdk.java.net>

Changeset: abb221aa23e4
Author:    martin
Date:      2009-07-24 18:16 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/abb221aa23e4

6639443: Character.toCodePoint and Character.toSurrogates can be optimized
Summary: rearranging code saves 5 bytes of bytecode
Reviewed-by: sherman

! src/share/classes/java/lang/Character.java

Changeset: e749fe2ed114
Author:    martin
Date:      2009-07-24 18:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e749fe2ed114

6639458: Improvements to Surrogate.java
Summary: Optimize Surrogate.java
Reviewed-by: sherman

! src/share/classes/sun/nio/cs/Surrogate.java



From unbelievable_evidence at yahoo.com  Sun Jul 26 19:41:42 2009
From: unbelievable_evidence at yahoo.com (cutcutcut cutcutcut)
Date: Sun, 26 Jul 2009 12:41:42 -0700 (PDT)
Subject: fast math
Message-ID: <195416.11375.qm@web38705.mail.mud.yahoo.com>

Hello.

I did write some faster (but yet not sloppy) versions of java.lang.Math class treatments.

In short, they are about 2-3 times faster (from 1 to 15 times), with usually about 1e-15 absolute or relative accuracy, handle special cases (NaN, etc.), and abs(cos(foo)) will never be > 1... I think!

If you think they could fit in some OpenJDK release, you can get them on sourceforge (they are under LGPL license) ; just look for "java fast math".

Bye.





      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090726/893082dd/attachment.html>

From joe.darcy at sun.com  Mon Jul 27 04:32:53 2009
From: joe.darcy at sun.com (joe.darcy at sun.com)
Date: Mon, 27 Jul 2009 04:32:53 +0000
Subject: hg: jdk7/tl/langtools: 6381698: Warn of decommissioning of apt
Message-ID: <20090727043257.B31AEE811@hg.openjdk.java.net>

Changeset: d043adadc8b6
Author:    darcy
Date:      2009-07-26 21:27 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d043adadc8b6

6381698: Warn of decommissioning of apt
Reviewed-by: jjg

! make/build.properties
! src/share/classes/com/sun/mirror/apt/AnnotationProcessor.java
! src/share/classes/com/sun/mirror/apt/AnnotationProcessorEnvironment.java
! src/share/classes/com/sun/mirror/apt/AnnotationProcessorFactory.java
! src/share/classes/com/sun/mirror/apt/AnnotationProcessorListener.java
! src/share/classes/com/sun/mirror/apt/AnnotationProcessors.java
! src/share/classes/com/sun/mirror/apt/Filer.java
! src/share/classes/com/sun/mirror/apt/Messager.java
! src/share/classes/com/sun/mirror/apt/RoundCompleteEvent.java
! src/share/classes/com/sun/mirror/apt/RoundCompleteListener.java
! src/share/classes/com/sun/mirror/apt/RoundState.java
+ src/share/classes/com/sun/mirror/apt/package-info.java
- src/share/classes/com/sun/mirror/apt/package.html
! src/share/classes/com/sun/mirror/declaration/AnnotationMirror.java
! src/share/classes/com/sun/mirror/declaration/AnnotationTypeDeclaration.java
! src/share/classes/com/sun/mirror/declaration/AnnotationTypeElementDeclaration.java
! src/share/classes/com/sun/mirror/declaration/AnnotationValue.java
! src/share/classes/com/sun/mirror/declaration/ClassDeclaration.java
! src/share/classes/com/sun/mirror/declaration/ConstructorDeclaration.java
! src/share/classes/com/sun/mirror/declaration/Declaration.java
! src/share/classes/com/sun/mirror/declaration/EnumConstantDeclaration.java
! src/share/classes/com/sun/mirror/declaration/EnumDeclaration.java
! src/share/classes/com/sun/mirror/declaration/ExecutableDeclaration.java
! src/share/classes/com/sun/mirror/declaration/FieldDeclaration.java
! src/share/classes/com/sun/mirror/declaration/InterfaceDeclaration.java
! src/share/classes/com/sun/mirror/declaration/MemberDeclaration.java
! src/share/classes/com/sun/mirror/declaration/MethodDeclaration.java
! src/share/classes/com/sun/mirror/declaration/Modifier.java
! src/share/classes/com/sun/mirror/declaration/PackageDeclaration.java
! src/share/classes/com/sun/mirror/declaration/ParameterDeclaration.java
! src/share/classes/com/sun/mirror/declaration/TypeDeclaration.java
! src/share/classes/com/sun/mirror/declaration/TypeParameterDeclaration.java
+ src/share/classes/com/sun/mirror/declaration/package-info.java
- src/share/classes/com/sun/mirror/declaration/package.html
! src/share/classes/com/sun/mirror/type/AnnotationType.java
! src/share/classes/com/sun/mirror/type/ArrayType.java
! src/share/classes/com/sun/mirror/type/ClassType.java
! src/share/classes/com/sun/mirror/type/DeclaredType.java
! src/share/classes/com/sun/mirror/type/EnumType.java
! src/share/classes/com/sun/mirror/type/InterfaceType.java
! src/share/classes/com/sun/mirror/type/MirroredTypeException.java
! src/share/classes/com/sun/mirror/type/MirroredTypesException.java
! src/share/classes/com/sun/mirror/type/PrimitiveType.java
! src/share/classes/com/sun/mirror/type/ReferenceType.java
! src/share/classes/com/sun/mirror/type/TypeMirror.java
! src/share/classes/com/sun/mirror/type/TypeVariable.java
! src/share/classes/com/sun/mirror/type/VoidType.java
! src/share/classes/com/sun/mirror/type/WildcardType.java
+ src/share/classes/com/sun/mirror/type/package-info.java
- src/share/classes/com/sun/mirror/type/package.html
! src/share/classes/com/sun/mirror/util/DeclarationFilter.java
! src/share/classes/com/sun/mirror/util/DeclarationScanner.java
! src/share/classes/com/sun/mirror/util/DeclarationVisitor.java
! src/share/classes/com/sun/mirror/util/DeclarationVisitors.java
! src/share/classes/com/sun/mirror/util/Declarations.java
! src/share/classes/com/sun/mirror/util/SimpleDeclarationVisitor.java
! src/share/classes/com/sun/mirror/util/SimpleTypeVisitor.java
! src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java
! src/share/classes/com/sun/mirror/util/SourcePosition.java
! src/share/classes/com/sun/mirror/util/TypeVisitor.java
! src/share/classes/com/sun/mirror/util/Types.java
+ src/share/classes/com/sun/mirror/util/package-info.java
- src/share/classes/com/sun/mirror/util/package.html
! src/share/classes/com/sun/tools/apt/comp/Apt.java
! src/share/classes/com/sun/tools/apt/comp/BootstrapAPF.java
! src/share/classes/com/sun/tools/apt/comp/PrintAP.java
! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java
! src/share/classes/com/sun/tools/apt/main/Main.java
! src/share/classes/com/sun/tools/apt/mirror/AptEnv.java
! src/share/classes/com/sun/tools/apt/mirror/apt/AnnotationProcessorEnvironmentImpl.java
! src/share/classes/com/sun/tools/apt/mirror/apt/FilerImpl.java
! src/share/classes/com/sun/tools/apt/mirror/apt/MessagerImpl.java
! src/share/classes/com/sun/tools/apt/mirror/apt/RoundCompleteEventImpl.java
! src/share/classes/com/sun/tools/apt/mirror/apt/RoundStateImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationMirrorImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationTypeElementDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationValueImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/ClassDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/Constants.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/ConstructorDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationMaker.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/EnumConstantDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/EnumDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/ExecutableDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/FieldDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/InterfaceDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/MemberDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/MethodDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/PackageDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/ParameterDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/TypeDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/declaration/TypeParameterDeclarationImpl.java
! src/share/classes/com/sun/tools/apt/mirror/type/AnnotationTypeImpl.java
! src/share/classes/com/sun/tools/apt/mirror/type/ArrayTypeImpl.java
! src/share/classes/com/sun/tools/apt/mirror/type/ClassTypeImpl.java
! src/share/classes/com/sun/tools/apt/mirror/type/DeclaredTypeImpl.java
! src/share/classes/com/sun/tools/apt/mirror/type/EnumTypeImpl.java
! src/share/classes/com/sun/tools/apt/mirror/type/InterfaceTypeImpl.java
! src/share/classes/com/sun/tools/apt/mirror/type/PrimitiveTypeImpl.java
! src/share/classes/com/sun/tools/apt/mirror/type/TypeMaker.java
! src/share/classes/com/sun/tools/apt/mirror/type/TypeMirrorImpl.java
! src/share/classes/com/sun/tools/apt/mirror/type/TypeVariableImpl.java
! src/share/classes/com/sun/tools/apt/mirror/type/VoidTypeImpl.java
! src/share/classes/com/sun/tools/apt/mirror/type/WildcardTypeImpl.java
! src/share/classes/com/sun/tools/apt/mirror/util/DeclarationsImpl.java
! src/share/classes/com/sun/tools/apt/mirror/util/SourcePositionImpl.java
! src/share/classes/com/sun/tools/apt/mirror/util/TypesImpl.java
! src/share/classes/com/sun/tools/apt/resources/apt.properties
! test/tools/apt/Basics/apt.sh
! test/tools/apt/Compile/compile.sh



From amalakov at deltixlab.com  Mon Jul 27 13:13:26 2009
From: amalakov at deltixlab.com (Andy Malakov)
Date: Mon, 27 Jul 2009 09:13:26 -0400
Subject: Logger.log (Level, String msg, Object... vargs)
Message-ID: <7B11951D726D413FA5A30765BE1FD371@Andy>

Hello All,

Will it be possible to add var-args logging method to 
java.util.logging.Logger class?

It will be nice to have

Logger.log (Level level, String msg, Object ... varags) in addition to 
existing Logger.log (Level level, String msg, Object [] varags) ?

So that one can write

logger.log (Level.FINEST, "User {0} submitted {1}", user, request)

rather than

logger.log (Level.FINEST, "User {0} submitted {1}", new Object [] { user, 
request}) ?

If this is not the right place to post such suggestions, please advise where 
should I go?

Best regards,
Andy 



From Alan.Bateman at Sun.COM  Mon Jul 27 14:12:59 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Mon, 27 Jul 2009 15:12:59 +0100
Subject: Logger.log (Level, String msg, Object... vargs)
In-Reply-To: <7B11951D726D413FA5A30765BE1FD371@Andy>
References: <7B11951D726D413FA5A30765BE1FD371@Andy>
Message-ID: <4A6DB5EB.7050604@sun.com>

Andy Malakov wrote:
> Hello All,
>
> Will it be possible to add var-args logging method to 
> java.util.logging.Logger class?
>
> It will be nice to have
>
> Logger.log (Level level, String msg, Object ... varags) in addition to 
> existing Logger.log (Level level, String msg, Object [] varags) ?
>
> So that one can write
>
> logger.log (Level.FINEST, "User {0} submitted {1}", user, request)
>
> rather than
>
> logger.log (Level.FINEST, "User {0} submitted {1}", new Object [] { 
> user, request}) ?
>
> If this is not the right place to post such suggestions, please advise 
> where should I go?
>
> Best regards,
> Andy
It has come a few times (see [1], [2], and the linked bugs). It just 
needs a volunteer to run with it, check for any issues, etc.

-Alan.

[1] http://bugs.sun.com/view_bug.do?bug_id=5001993
[2] http://bugs.sun.com/view_bug.do?bug_id=6540440




From xuelei.fan at sun.com  Mon Jul 27 14:17:35 2009
From: xuelei.fan at sun.com (xuelei.fan at sun.com)
Date: Mon, 27 Jul 2009 14:17:35 +0000
Subject: hg: jdk7/tl/jdk: 6449574: Invalid ldap filter is accepted and
	processed
Message-ID: <20090727141819.5CE51E887@hg.openjdk.java.net>

Changeset: d78bfd73ee42
Author:    xuelei
Date:      2009-07-27 22:04 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d78bfd73ee42

6449574: Invalid ldap filter is accepted and processed
Reviewed-by: vinnie

! src/share/classes/com/sun/jndi/ldap/Filter.java
+ test/com/sun/jndi/ldap/BalancedParentheses.java



From ebourg at apache.org  Mon Jul 27 14:26:51 2009
From: ebourg at apache.org (Emmanuel Bourg)
Date: Mon, 27 Jul 2009 16:26:51 +0200
Subject: Logger.log (Level, String msg, Object... vargs)
In-Reply-To: <4A6DB5EB.7050604@sun.com>
References: <7B11951D726D413FA5A30765BE1FD371@Andy> <4A6DB5EB.7050604@sun.com>
Message-ID: <4A6DB92B.3070903@apache.org>

Alan Bateman a ?crit :

> It has come a few times (see [1], [2], and the linked bugs). It just 
> needs a volunteer to run with it, check for any issues, etc.
> 
> -Alan.
> 
> [1] http://bugs.sun.com/view_bug.do?bug_id=5001993
> [2] http://bugs.sun.com/view_bug.do?bug_id=6540440

Hi,

I'm also interested in these changes. Does it require a formal process 
(JCP or anything else) to be included in the JDK? If I were to implement 
these improvements, who could I contact to review the patch and apply it?

Thank you,

Emmanuel Bourg


From Alan.Bateman at Sun.COM  Mon Jul 27 17:37:02 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Mon, 27 Jul 2009 18:37:02 +0100
Subject: Logger.log (Level, String msg, Object... vargs)
In-Reply-To: <4A6DB92B.3070903@apache.org>
References: <7B11951D726D413FA5A30765BE1FD371@Andy> <4A6DB5EB.7050604@sun.com>
	<4A6DB92B.3070903@apache.org>
Message-ID: <4A6DE5BE.7070200@sun.com>

Emmanuel Bourg wrote:
> :
> Hi,
>
> I'm also interested in these changes. Does it require a formal process 
> (JCP or anything else) to be included in the JDK? If I were to 
> implement these improvements, who could I contact to review the patch 
> and apply it?
>
> Thank you,
>
> Emmanuel Bourg
The "How to contribute" page is the place to start.

-Alan.

[1] http://openjdk.java.net/contribute/


From alan.bateman at sun.com  Mon Jul 27 21:29:03 2009
From: alan.bateman at sun.com (alan.bateman at sun.com)
Date: Mon, 27 Jul 2009 21:29:03 +0000
Subject: hg: jdk7/tl/jdk: 3 new changesets
Message-ID: <20090727213038.6EAAAE95E@hg.openjdk.java.net>

Changeset: 3eb4506815b6
Author:    alanb
Date:      2009-07-27 18:44 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3eb4506815b6

6863864: (fs) Path.createSymbolicLink doesn't set directory flag when creating sym link to directory (win)
Reviewed-by: sherman

! src/windows/classes/sun/nio/fs/WindowsPath.java
! test/java/nio/file/Path/Links.java

Changeset: 6fcddeeadd8c
Author:    alanb
Date:      2009-07-27 18:46 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6fcddeeadd8c

6863667: (ch) Several tests in java/nio/channels/* need to be updated after 6638712
Reviewed-by: mcimadamore

! test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java
! test/java/nio/channels/AsynchronousChannelGroup/Identity.java
! test/java/nio/channels/AsynchronousChannelGroup/Restart.java
! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java
! test/java/nio/channels/AsynchronousDatagramChannel/Basic.java
! test/java/nio/channels/AsynchronousFileChannel/Basic.java
! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java
! test/java/nio/channels/AsynchronousSocketChannel/Basic.java
! test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java

Changeset: 74c4b8c743fb
Author:    alanb
Date:      2009-07-27 19:22 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/74c4b8c743fb

6864319: (fs) Eliminate static dependency on fdopendir (lnx)
Reviewed-by: martin

! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c



From jonathan.gibbons at sun.com  Mon Jul 27 22:27:22 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Mon, 27 Jul 2009 22:27:22 +0000
Subject: hg: jdk7/tl: 6854244: change source/target used to compile JDK to 7
Message-ID: <20090727222723.172E4E98D@hg.openjdk.java.net>

Changeset: 59c202ab8a94
Author:    jjg
Date:      2009-07-27 15:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/rev/59c202ab8a94

6854244: change source/target used to compile JDK to 7
Reviewed-by: ohair

! make/README.pre-components



From jonathan.gibbons at sun.com  Mon Jul 27 22:33:08 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Mon, 27 Jul 2009 22:33:08 +0000
Subject: hg: jdk7/tl/langtools: 6854244: change source/target used to compile
	JDK to 7
Message-ID: <20090727223315.0D2DEE992@hg.openjdk.java.net>

Changeset: cf08b64e87da
Author:    jjg
Date:      2009-07-27 15:20 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/cf08b64e87da

6854244: change source/target used to compile JDK to 7
Reviewed-by: ohair

! make/build.properties



From jonathan.gibbons at sun.com  Mon Jul 27 22:38:54 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Mon, 27 Jul 2009 22:38:54 +0000
Subject: hg: jdk7/tl/corba: 6854244: change source/target used to compile JDK
	to 7
Message-ID: <20090727223855.94AF2E99A@hg.openjdk.java.net>

Changeset: 2a160e4e0d06
Author:    jjg
Date:      2009-07-27 15:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/corba/rev/2a160e4e0d06

6854244: change source/target used to compile JDK to 7
Reviewed-by: ohair

! make/Makefile
! make/common/shared/Defs-java.gmk



From jonathan.gibbons at sun.com  Mon Jul 27 22:44:37 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Mon, 27 Jul 2009 22:44:37 +0000
Subject: hg: jdk7/tl/jdk: 6854244: change source/target used to compile JDK to
	7
Message-ID: <20090727224509.84716E99F@hg.openjdk.java.net>

Changeset: 15878be84b9d
Author:    jjg
Date:      2009-07-27 15:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/15878be84b9d

6854244: change source/target used to compile JDK to 7
Reviewed-by: ohair

! make/common/shared/Defs-control.gmk
! make/common/shared/Defs-java.gmk
! make/java/dyn/Makefile



From jonathan.gibbons at sun.com  Mon Jul 27 22:50:46 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Mon, 27 Jul 2009 22:50:46 +0000
Subject: hg: jdk7/tl/jaxws: 6854244: change source/target used to compile JDK
	to 7
Message-ID: <20090727225048.50B8FE9A5@hg.openjdk.java.net>

Changeset: c5dfd37d18a0
Author:    jjg
Date:      2009-07-27 15:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/c5dfd37d18a0

6854244: change source/target used to compile JDK to 7
Reviewed-by: ohair

! make/build.properties



From jonathan.gibbons at sun.com  Mon Jul 27 22:56:20 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Mon, 27 Jul 2009 22:56:20 +0000
Subject: hg: jdk7/tl/jaxp: 6854244: change source/target used to compile JDK
	to 7
Message-ID: <20090727225622.6F529E9AB@hg.openjdk.java.net>

Changeset: 59cdcbf2c10d
Author:    jjg
Date:      2009-07-27 15:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/59cdcbf2c10d

6854244: change source/target used to compile JDK to 7
Reviewed-by: ohair

! make/build.properties



From jonathan.gibbons at sun.com  Tue Jul 28 03:00:53 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 28 Jul 2009 03:00:53 +0000
Subject: hg: jdk7/tl/langtools: 6865399: some javac files are missing Sun
	internal API comment
Message-ID: <20090728030059.7F7CAE9DC@hg.openjdk.java.net>

Changeset: 7c2d6da61646
Author:    jjg
Date:      2009-07-27 19:52 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7c2d6da61646

6865399: some javac files are missing Sun internal API comment
Reviewed-by: darcy

! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/api/Formattable.java
! src/share/classes/com/sun/tools/javac/api/Messages.java
! src/share/classes/com/sun/tools/javac/code/BoundKind.java
! src/share/classes/com/sun/tools/javac/code/Printer.java
! src/share/classes/com/sun/tools/javac/file/BaseFileObject.java
! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java
! src/share/classes/com/sun/tools/javac/file/FSInfo.java
! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java
! src/share/classes/com/sun/tools/javac/file/RegularFileObject.java
! src/share/classes/com/sun/tools/javac/file/RelativePath.java
! src/share/classes/com/sun/tools/javac/file/SymbolArchive.java
! src/share/classes/com/sun/tools/javac/file/ZipArchive.java
! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java
! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java
! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java
! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/ForwardingDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
! src/share/classes/com/sun/tools/javac/util/Warner.java



From xuelei.fan at sun.com  Tue Jul 28 03:27:59 2009
From: xuelei.fan at sun.com (xuelei.fan at sun.com)
Date: Tue, 28 Jul 2009 03:27:59 +0000
Subject: hg: jdk7/tl/jdk: 6865482: test case BalancedParentheses.java is
	missing GPL header.
Message-ID: <20090728032837.A01E4E9E5@hg.openjdk.java.net>

Changeset: 056c8e724015
Author:    xuelei
Date:      2009-07-28 11:15 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/056c8e724015

6865482: test case BalancedParentheses.java is missing GPL header.
Reviewed-by: weijun

! test/com/sun/jndi/ldap/BalancedParentheses.java



From gnu_andrew at member.fsf.org  Tue Jul 28 12:24:48 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Tue, 28 Jul 2009 13:24:48 +0100
Subject: execvpe and glibc 2.10
In-Reply-To: <1ccfd1c10907091407q1557c49s6338614925808a23@mail.gmail.com>
References: <1ccfd1c10907091407q1557c49s6338614925808a23@mail.gmail.com>
Message-ID: <17c6771e0907280524t40a84dbem94e73030f93499e5@mail.gmail.com>

2009/7/9 Martin Buchholz <martinrb at google.com>:
> Sorry, I should never have named a function (not even a static one)
> 'execvpe'.? It's amusing that I broke myself by requesting that glibc
> implement 'execvpe'.
>
> Here's the webrev:
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/rename-execvpe/
>
> For those following things, there are now 3 pending patches for
> UNIXProcess_md.c:
>
> rename-execvpe
> vfork-exec
> RESTARTABLE
>
> and there are more to come.
>
> Martin
>
> On Thu, Jul 9, 2009 at 12:32, Lillian Angel <langel at redhat.com> wrote:
>>
>> Hi Martin,
>>
>> I am having trouble building IcedTea6 on Fedora 12
>> (http://koji.fedoraproject.org/koji/getfile?taskID=1463798&name=build.log),
>> it seems because this bug was fixed in glibc-2.10-3:
>> http://sourceware.org/bugzilla/show_bug.cgi?id=10221
>>
>> Do you have a patch for IcedTea/OpenJDK to get around this?
>>
>

Martin,

What happened to this patch? Has it been pushed to 6/7?

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Michael.McMahon at Sun.COM  Tue Jul 28 12:43:55 2009
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Tue, 28 Jul 2009 13:43:55 +0100
Subject: execvpe and glibc 2.10
In-Reply-To: <17c6771e0907280524t40a84dbem94e73030f93499e5@mail.gmail.com>
References: <1ccfd1c10907091407q1557c49s6338614925808a23@mail.gmail.com>
	<17c6771e0907280524t40a84dbem94e73030f93499e5@mail.gmail.com>
Message-ID: <4A6EF28B.8040302@sun.com>

Andrew John Hughes wrote:
> 2009/7/9 Martin Buchholz <martinrb at google.com>:
>   
>> Sorry, I should never have named a function (not even a static one)
>> 'execvpe'.  It's amusing that I broke myself by requesting that glibc
>> implement 'execvpe'.
>>
>> Here's the webrev:
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/rename-execvpe/
>>
>> For those following things, there are now 3 pending patches for
>> UNIXProcess_md.c:
>>
>> rename-execvpe
>> vfork-exec
>> RESTARTABLE
>>
>> and there are more to come.
>>
>> Martin
>>
>> On Thu, Jul 9, 2009 at 12:32, Lillian Angel <langel at redhat.com> wrote:
>>     
>>> Hi Martin,
>>>
>>> I am having trouble building IcedTea6 on Fedora 12
>>> (http://koji.fedoraproject.org/koji/getfile?taskID=1463798&name=build.log),
>>> it seems because this bug was fixed in glibc-2.10-3:
>>> http://sourceware.org/bugzilla/show_bug.cgi?id=10221
>>>
>>> Do you have a patch for IcedTea/OpenJDK to get around this?
>>>
>>>       
>
> Martin,
>
> What happened to this patch? Has it been pushed to 6/7?
>
> Thanks,
>   
No, it hasn't been pushed yet. The vfork-exec one in particular
needs some more testing before it can be pushed.

Michael.


From gnu_andrew at member.fsf.org  Tue Jul 28 12:51:47 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Tue, 28 Jul 2009 13:51:47 +0100
Subject: execvpe and glibc 2.10
In-Reply-To: <4A6EF28B.8040302@sun.com>
References: <1ccfd1c10907091407q1557c49s6338614925808a23@mail.gmail.com>
	<17c6771e0907280524t40a84dbem94e73030f93499e5@mail.gmail.com>
	<4A6EF28B.8040302@sun.com>
Message-ID: <17c6771e0907280551t7ef565ebw22f6a2d102065de7@mail.gmail.com>

2009/7/28 Michael McMahon <Michael.McMahon at sun.com>:
> Andrew John Hughes wrote:
>>
>> 2009/7/9 Martin Buchholz <martinrb at google.com>:
>>
>>>
>>> Sorry, I should never have named a function (not even a static one)
>>> 'execvpe'. ?It's amusing that I broke myself by requesting that glibc
>>> implement 'execvpe'.
>>>
>>> Here's the webrev:
>>>
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/rename-execvpe/
>>>
>>> For those following things, there are now 3 pending patches for
>>> UNIXProcess_md.c:
>>>
>>> rename-execvpe
>>> vfork-exec
>>> RESTARTABLE
>>>
>>> and there are more to come.
>>>
>>> Martin
>>>
>>> On Thu, Jul 9, 2009 at 12:32, Lillian Angel <langel at redhat.com> wrote:
>>>
>>>>
>>>> Hi Martin,
>>>>
>>>> I am having trouble building IcedTea6 on Fedora 12
>>>>
>>>> (http://koji.fedoraproject.org/koji/getfile?taskID=1463798&name=build.log),
>>>> it seems because this bug was fixed in glibc-2.10-3:
>>>> http://sourceware.org/bugzilla/show_bug.cgi?id=10221
>>>>
>>>> Do you have a patch for IcedTea/OpenJDK to get around this?
>>>>
>>>>
>>
>> Martin,
>>
>> What happened to this patch? Has it been pushed to 6/7?
>>
>> Thanks,
>>
>
> No, it hasn't been pushed yet. The vfork-exec one in particular
> needs some more testing before it can be pushed.
>
> Michael.
>

rename-execvpe is the one I'm particularly concerned about.  It's a
trivial patch, but without it, OpenJDK builds are going to start
failing as distros move to the new glibc (e.g. Fedora 12).  It's
already an issue for users of Fedora rawhide.
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From Michael.McMahon at Sun.COM  Tue Jul 28 13:08:23 2009
From: Michael.McMahon at Sun.COM (Michael McMahon)
Date: Tue, 28 Jul 2009 14:08:23 +0100
Subject: execvpe and glibc 2.10
In-Reply-To: <17c6771e0907280551t7ef565ebw22f6a2d102065de7@mail.gmail.com>
References: <1ccfd1c10907091407q1557c49s6338614925808a23@mail.gmail.com>
	<17c6771e0907280524t40a84dbem94e73030f93499e5@mail.gmail.com>
	<4A6EF28B.8040302@sun.com>
	<17c6771e0907280551t7ef565ebw22f6a2d102065de7@mail.gmail.com>
Message-ID: <4A6EF847.3030709@sun.com>

Andrew John Hughes wrote:
> 2009/7/28 Michael McMahon <Michael.McMahon at sun.com>:
>   
>> Andrew John Hughes wrote:
>>     
>>> 2009/7/9 Martin Buchholz <martinrb at google.com>:
>>>
>>>       
>>
>
> rename-execvpe is the one I'm particularly concerned about.  It's a
> trivial patch, but without it, OpenJDK builds are going to start
> failing as distros move to the new glibc (e.g. Fedora 12).  It's
> already an issue for users of Fedora rawhide.
>   

Ok. Maybe we can push rename-execvpe and RESTARTABLE first.

- Michael.


From martinrb at google.com  Tue Jul 28 14:47:27 2009
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 28 Jul 2009 07:47:27 -0700
Subject: execvpe and glibc 2.10
In-Reply-To: <4A6EF847.3030709@sun.com>
References: <1ccfd1c10907091407q1557c49s6338614925808a23@mail.gmail.com>
	<17c6771e0907280524t40a84dbem94e73030f93499e5@mail.gmail.com>
	<4A6EF28B.8040302@sun.com>
	<17c6771e0907280551t7ef565ebw22f6a2d102065de7@mail.gmail.com>
	<4A6EF847.3030709@sun.com>
Message-ID: <1ccfd1c10907280747r11681293k232bab01aa78679@mail.gmail.com>

On Tue, Jul 28, 2009 at 06:08, Michael McMahon<Michael.McMahon at sun.com> wrote:
> Andrew John Hughes wrote:
>>
>> 2009/7/28 Michael McMahon <Michael.McMahon at sun.com>:
>>
>>>
>>> Andrew John Hughes wrote:
>>>
>>>>
>>>> 2009/7/9 Martin Buchholz <martinrb at google.com>:
>>>>
>>>>
>>>
>>
>> rename-execvpe is the one I'm particularly concerned about. ?It's a
>> trivial patch, but without it, OpenJDK builds are going to start
>> failing as distros move to the new glibc (e.g. Fedora 12). ?It's
>> already an issue for users of Fedora rawhide.
>>
>
> Ok. Maybe we can push rename-execvpe and RESTARTABLE first.

RESTARTABLE depends on vfork-exec, and I would not like to do
the work to reorder them.

Changes to fork-exec are always high-risk,
and I would like to see some more testing on these
before committing to openjdk proper.
That could be done by having icedtea7 import them,
and by having Michael or another Sun person run them
through Sun testing.

There are more changes to fork-exec to come,
although they will probably not affect the average Linux user's
experience.

Michael and I have been doing other things the past few weeks.

Martin


From jonathan.gibbons at sun.com  Tue Jul 28 17:44:09 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 28 Jul 2009 17:44:09 +0000
Subject: hg: jdk7/tl/langtools: 6855990: javap InstructionDetailWriter should
	support new 308 annotations attribute
Message-ID: <20090728174416.7E4BCEA83@hg.openjdk.java.net>

Changeset: 777a3efad0d5
Author:    jjg
Date:      2009-07-28 10:36 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/777a3efad0d5

6855990: javap InstructionDetailWriter should support new 308 annotations attribute
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java
! src/share/classes/com/sun/tools/javap/AnnotationWriter.java
! src/share/classes/com/sun/tools/javap/CodeWriter.java
! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java
+ src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java
+ test/tools/javap/typeAnnotations/T6855990.java



From jonathan.gibbons at sun.com  Tue Jul 28 18:08:48 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Tue, 28 Jul 2009 18:08:48 +0000
Subject: hg: jdk7/tl/langtools: 6734068: Some variable length attributes set
	their size incorrectly.
Message-ID: <20090728180853.2014FEA88@hg.openjdk.java.net>

Changeset: 85b317ac8a0c
Author:    jjg
Date:      2009-07-28 11:00 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/85b317ac8a0c

6734068: Some variable length attributes set their size incorrectly.
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/classfile/CharacterRangeTable_attribute.java
! src/share/classes/com/sun/tools/classfile/LineNumberTable_attribute.java
! src/share/classes/com/sun/tools/classfile/LocalVariableTable_attribute.java
! src/share/classes/com/sun/tools/classfile/LocalVariableTypeTable_attribute.java
! src/share/classes/com/sun/tools/classfile/ModuleExportTable_attribute.java
! src/share/classes/com/sun/tools/classfile/ModuleMemberTable_attribute.java



From martinrb at google.com  Tue Jul 28 23:09:27 2009
From: martinrb at google.com (martinrb at google.com)
Date: Tue, 28 Jul 2009 23:09:27 +0000
Subject: hg: jdk7/tl/jdk: 6785442: ConcurrentLinkedQueue.remove() and poll()
	can both remove the same element; ...
Message-ID: <20090728231003.CFCF2EB03@hg.openjdk.java.net>

Changeset: 12e479399ced
Author:    dl
Date:      2009-07-28 13:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/12e479399ced

6785442: ConcurrentLinkedQueue.remove() and poll() can both remove the same element
6493942: ConcurrentLinkedQueue.remove sometimes very slow
Summary: new algorithm for handling concurrent linked lists
Reviewed-by: martin

! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
- test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java
- test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java
+ test/java/util/concurrent/ConcurrentQueues/ConcurrentQueueLoops.java
+ test/java/util/concurrent/ConcurrentQueues/GCRetention.java
+ test/java/util/concurrent/ConcurrentQueues/LoopHelpers.java
+ test/java/util/concurrent/ConcurrentQueues/RemovePollRace.java
! test/java/util/concurrent/LinkedBlockingQueue/OfferRemoveLoops.java



From martinrb at google.com  Wed Jul 29 00:25:22 2009
From: martinrb at google.com (martinrb at google.com)
Date: Wed, 29 Jul 2009 00:25:22 +0000
Subject: hg: jdk7/tl/jdk: 6805775: LinkedBlockingQueue Nodes should unlink
	themselves before becoming garbage; ...
Message-ID: <20090729002558.5839EEB10@hg.openjdk.java.net>

Changeset: 49573ab3096a
Author:    dl
Date:      2009-07-28 17:17 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/49573ab3096a

6805775: LinkedBlockingQueue Nodes should unlink themselves before becoming garbage
6815766: LinkedBlockingQueue's iterator can return null if drainTo(c) executes concurrently
Summary: Faster, more correct. Use self-linking trick to avoid gc retention
Reviewed-by: martin, dholmes

! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! test/java/util/Collection/MOAT.java
+ test/java/util/concurrent/BlockingQueue/OfferDrainToLoops.java
+ test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java



From Anthony.Petrov at Sun.COM  Wed Jul 29 11:13:22 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 29 Jul 2009 15:13:22 +0400
Subject: Review request #0: 6863566 (Java should support the freedesktop.org
	startup notification specification)
Message-ID: <4A702ED2.1040804@sun.com>

Hello,

Please review the fix contributed by Damjan Jovanovic:

RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094

webrev: http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.0/

Since the patch includes changes to the src/solaris/bin/java_md.c, I'm 
CC'ing Kumar and Core Libs alias to review the changes in that file.


Damjan, have you by the way tested the fix with a GUI Java application 
that does not display a top-level window, but rather creates a tray icon 
only? Does the notification get correctly removed from the task bar in 
that case?

--
best regards,
Anthony


From Alan.Bateman at Sun.COM  Wed Jul 29 12:10:11 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Wed, 29 Jul 2009 13:10:11 +0100
Subject: Review request #0: 6863566 (Java should support the
	freedesktop.org startup notification specification)
In-Reply-To: <4A702ED2.1040804@sun.com>
References: <4A702ED2.1040804@sun.com>
Message-ID: <4A703C23.1000701@sun.com>

Anthony Petrov wrote:
> Hello,
>
> Please review the fix contributed by Damjan Jovanovic:
>
> RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094
>
> webrev: http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.0/
>
> Since the patch includes changes to the src/solaris/bin/java_md.c, I'm 
> CC'ing Kumar and Core Libs alias to review the changes in that file.
>
>
> Damjan, have you by the way tested the fix with a GUI Java application 
> that does not display a top-level window, but rather creates a tray 
> icon only? Does the notification get correctly removed from the task 
> bar in that case?
>
> -- 
> best regards,
> Anthony
I think Kumar is on vacation at the moment.

Out of curiosity, are the launcher changes really needed? I assume this 
startup notification protocol is only interesting to applications with a 
user interface and maybe it would be okay to just grab/unset the 
environment variable when the base window becomes visible. Is the 
concern that the environment variable will leak into sub-processes 
created before the window becomes visible? Also, I wonder about 
applications that launch the VM via the JNI invocation API. This would 
require documenting the system property for this to work.

In passing, I see removeStartupNotification reads the system property. I 
don't know the call stack here but are all the caller frames for methods 
on the boot class path? Just wondering about when there is a security 
manager and if it needs to be in doPrivileged block.

-Alan.






From gnu_andrew at member.fsf.org  Wed Jul 29 15:24:10 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 29 Jul 2009 16:24:10 +0100
Subject: execvpe and glibc 2.10
In-Reply-To: <1ccfd1c10907280747r11681293k232bab01aa78679@mail.gmail.com>
References: <1ccfd1c10907091407q1557c49s6338614925808a23@mail.gmail.com>
	<17c6771e0907280524t40a84dbem94e73030f93499e5@mail.gmail.com>
	<4A6EF28B.8040302@sun.com>
	<17c6771e0907280551t7ef565ebw22f6a2d102065de7@mail.gmail.com>
	<4A6EF847.3030709@sun.com>
	<1ccfd1c10907280747r11681293k232bab01aa78679@mail.gmail.com>
Message-ID: <17c6771e0907290824h158a60f2m441890db7ed3120d@mail.gmail.com>

2009/7/28 Martin Buchholz <martinrb at google.com>:
> On Tue, Jul 28, 2009 at 06:08, Michael McMahon<Michael.McMahon at sun.com> wrote:
>> Andrew John Hughes wrote:
>>>
>>> 2009/7/28 Michael McMahon <Michael.McMahon at sun.com>:
>>>
>>>>
>>>> Andrew John Hughes wrote:
>>>>
>>>>>
>>>>> 2009/7/9 Martin Buchholz <martinrb at google.com>:
>>>>>
>>>>>
>>>>
>>>
>>> rename-execvpe is the one I'm particularly concerned about. ?It's a
>>> trivial patch, but without it, OpenJDK builds are going to start
>>> failing as distros move to the new glibc (e.g. Fedora 12). ?It's
>>> already an issue for users of Fedora rawhide.
>>>
>>
>> Ok. Maybe we can push rename-execvpe and RESTARTABLE first.
>
> RESTARTABLE depends on vfork-exec, and I would not like to do
> the work to reorder them.
>
> Changes to fork-exec are always high-risk,
> and I would like to see some more testing on these
> before committing to openjdk proper.
> That could be done by having icedtea7 import them,
> and by having Michael or another Sun person run them
> through Sun testing.
>
> There are more changes to fork-exec to come,
> although they will probably not affect the average Linux user's
> experience.
>
> Michael and I have been doing other things the past few weeks.
>
> Martin
>

Sure, we can do some testing with IcedTea7 after the release for M4,
which should be sometime in the next week or so.

In the meantime, can you or me push the execvpe cleanup to the 6 and 7
forests (tl presumably for 7)?  Or is there a further issue there?
You've not mentioned it in either reply.

Joe, I assume this is okay for 6?  Without it the build is broken on
newer distributions.

Thanks,
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From son.two at gmail.com  Wed Jul 29 13:04:25 2009
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Wed, 29 Jul 2009 17:04:25 +0400
Subject: <AWT Dev> Review request #0: 6863566 (Java should support the 
	freedesktop.org startup notification specification)
In-Reply-To: <4A702ED2.1040804@sun.com>
References: <4A702ED2.1040804@sun.com>
Message-ID: <271e55d20907290604v1966cbe3wc42701675e533b19@mail.gmail.com>

Hi,

just a short question:
do we really have to change the launcher?  Why we can not add the
changes to AWT's native code (somewhere near LoadLibrary())?

Oleg.

On Wed, Jul 29, 2009 at 3:13 PM, Anthony Petrov<Anthony.Petrov at sun.com> wrote:
> Hello,
>
> Please review the fix contributed by Damjan Jovanovic:
>
> RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094
>
> webrev: http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.0/
>
> Since the patch includes changes to the src/solaris/bin/java_md.c, I'm
> CC'ing Kumar and Core Libs alias to review the changes in that file.
>
>
> Damjan, have you by the way tested the fix with a GUI Java application that
> does not display a top-level window, but rather creates a tray icon only?
> Does the notification get correctly removed from the task bar in that case?
>
> --
> best regards,
> Anthony
>


From xueming.shen at sun.com  Wed Jul 29 18:28:43 2009
From: xueming.shen at sun.com (xueming.shen at sun.com)
Date: Wed, 29 Jul 2009 18:28:43 +0000
Subject: hg: jdk7/tl/jdk: 3 new changesets
Message-ID: <20090729182939.4E538EB93@hg.openjdk.java.net>

Changeset: 8cabd2931621
Author:    sherman
Date:      2009-07-24 11:06 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8cabd2931621

5063507: (fmt) missing exception for "%#s" format specifier
Summary: throw appropriate exception when necessary
Reviewed-by: alanb

! src/share/classes/java/util/Formatter.java
! test/java/util/Formatter/Basic-X.java
! test/java/util/Formatter/Basic.java
! test/java/util/Formatter/BasicBigDecimal.java
! test/java/util/Formatter/BasicBigInteger.java
! test/java/util/Formatter/BasicBoolean.java
! test/java/util/Formatter/BasicBooleanObject.java
! test/java/util/Formatter/BasicByte.java
! test/java/util/Formatter/BasicByteObject.java
! test/java/util/Formatter/BasicChar.java
! test/java/util/Formatter/BasicCharObject.java
! test/java/util/Formatter/BasicDateTime.java
! test/java/util/Formatter/BasicDouble.java
! test/java/util/Formatter/BasicDoubleObject.java
! test/java/util/Formatter/BasicFloat.java
! test/java/util/Formatter/BasicFloatObject.java
! test/java/util/Formatter/BasicInt.java
! test/java/util/Formatter/BasicIntObject.java
! test/java/util/Formatter/BasicLong.java
! test/java/util/Formatter/BasicLongObject.java
! test/java/util/Formatter/BasicShort.java
! test/java/util/Formatter/BasicShortObject.java

Changeset: eb5173d782ca
Author:    sherman
Date:      2009-07-24 11:22 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eb5173d782ca

Merge


Changeset: eb27b5587e18
Author:    sherman
Date:      2009-07-29 11:19 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/eb27b5587e18

Merge

- test/java/util/concurrent/ConcurrentLinkedQueue/ConcurrentQueueLoops.java
- test/java/util/concurrent/ConcurrentLinkedQueue/LoopHelpers.java



From damjan.jov at gmail.com  Wed Jul 29 19:10:49 2009
From: damjan.jov at gmail.com (Damjan Jovanovic)
Date: Wed, 29 Jul 2009 21:10:49 +0200
Subject: Review request #0: 6863566 (Java should support the 
	freedesktop.org startup notification specification)
In-Reply-To: <4A702ED2.1040804@sun.com>
References: <4A702ED2.1040804@sun.com>
Message-ID: <9e89675b0907291210x2fa1f2cdt31f10fcf20d3ff8f@mail.gmail.com>

On Wed, Jul 29, 2009 at 1:13 PM, Anthony Petrov<Anthony.Petrov at sun.com> wrote:
> Hello,
>
> Please review the fix contributed by Damjan Jovanovic:
>
> RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094
>
> webrev: http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.0/
>
> Since the patch includes changes to the src/solaris/bin/java_md.c, I'm
> CC'ing Kumar and Core Libs alias to review the changes in that file.
>
>
> Damjan, have you by the way tested the fix with a GUI Java application that
> does not display a top-level window, but rather creates a tray icon only?
> Does the notification get correctly removed from the task bar in that case?

It doesn't :-(.

> --
> best regards,
> Anthony
>

Regards
Damjan


From damjan.jov at gmail.com  Wed Jul 29 19:27:45 2009
From: damjan.jov at gmail.com (Damjan Jovanovic)
Date: Wed, 29 Jul 2009 21:27:45 +0200
Subject: Review request #0: 6863566 (Java should support the 
	freedesktop.org startup notification specification)
In-Reply-To: <4A703C23.1000701@sun.com>
References: <4A702ED2.1040804@sun.com> <4A703C23.1000701@sun.com>
Message-ID: <9e89675b0907291227s14aa60dci1cdeb06ff10c50ec@mail.gmail.com>

On Wed, Jul 29, 2009 at 2:10 PM, Alan Bateman<Alan.Bateman at sun.com> wrote:
> Anthony Petrov wrote:
>>
>> Hello,
>>
>> Please review the fix contributed by Damjan Jovanovic:
>>
>> RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094
>>
>> webrev: http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.0/
>>
>> Since the patch includes changes to the src/solaris/bin/java_md.c, I'm
>> CC'ing Kumar and Core Libs alias to review the changes in that file.
>>
>>
>> Damjan, have you by the way tested the fix with a GUI Java application
>> that does not display a top-level window, but rather creates a tray icon
>> only? Does the notification get correctly removed from the task bar in that
>> case?
>>
>> --
>> best regards,
>> Anthony
>
> I think Kumar is on vacation at the moment.
>
> Out of curiosity, are the launcher changes really needed? I assume this
> startup notification protocol is only interesting to applications with a
> user interface and maybe it would be okay to just grab/unset the environment
> variable when the base window becomes visible. Is the concern that the
> environment variable will leak into sub-processes created before the window
> becomes visible? Also, I wonder about applications that launch the VM via
> the JNI invocation API. This would require documenting the system property
> for this to work.

Yes, subprocesses shouldn't inherit the environment variable, and the
specification also says it should be unset.

I thought about unsetting it later, but then there's a battle against
the environment variable caching in
jdk/src/solaris/classes/java/lang/ProcessEnvironment.java.

Any suggestions?

> In passing, I see removeStartupNotification reads the system property. I
> don't know the call stack here but are all the caller frames for methods on
> the boot class path? Just wondering about when there is a security manager
> and if it needs to be in doPrivileged block.

You're probably right, I see XToolkit defines a method that does
system property lookups in a doPrivileged block.

> -Alan.
>
>
>
>
>

Thank you
Damjan


From jonathan.gibbons at sun.com  Wed Jul 29 20:34:31 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Wed, 29 Jul 2009 20:34:31 +0000
Subject: hg: jdk7/tl/langtools: 4777949: Javap Rewrite : Warn javap usage on
	package classes with simple name.
Message-ID: <20090729203433.533B5EBB5@hg.openjdk.java.net>

Changeset: c2dfab9e2f39
Author:    jjg
Date:      2009-07-29 13:26 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c2dfab9e2f39

4777949: Javap Rewrite : Warn javap usage on package classes with simple name.
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javap/JavapFileManager.java
! src/share/classes/com/sun/tools/javap/JavapTask.java
! src/share/classes/com/sun/tools/javap/resources/javap.properties
+ test/tools/javap/T4777949.java



From martinrb at google.com  Wed Jul 29 21:04:25 2009
From: martinrb at google.com (martinrb at google.com)
Date: Wed, 29 Jul 2009 21:04:25 +0000
Subject: hg: jdk7/tl/jdk: 6866554: Misc. javadoc warnings
Message-ID: <20090729210500.5B9D4EBBE@hg.openjdk.java.net>

Changeset: 61d174a58edf
Author:    martin
Date:      2009-07-29 13:56 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/61d174a58edf

6866554: Misc. javadoc warnings
Reviewed-by: alanb

! src/share/classes/java/nio/channels/DatagramChannel.java
! src/share/classes/java/nio/channels/package-info.java
! src/share/classes/java/nio/file/DirectoryStream.java
! src/share/classes/java/nio/file/Path.java
! src/share/classes/java/nio/file/attribute/package-info.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java



From martinrb at google.com  Thu Jul 30 03:39:36 2009
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 29 Jul 2009 20:39:36 -0700
Subject: execvpe and glibc 2.10
In-Reply-To: <17c6771e0907290824h158a60f2m441890db7ed3120d@mail.gmail.com>
References: <1ccfd1c10907091407q1557c49s6338614925808a23@mail.gmail.com>
	<17c6771e0907280524t40a84dbem94e73030f93499e5@mail.gmail.com>
	<4A6EF28B.8040302@sun.com>
	<17c6771e0907280551t7ef565ebw22f6a2d102065de7@mail.gmail.com>
	<4A6EF847.3030709@sun.com>
	<1ccfd1c10907280747r11681293k232bab01aa78679@mail.gmail.com>
	<17c6771e0907290824h158a60f2m441890db7ed3120d@mail.gmail.com>
Message-ID: <1ccfd1c10907292039y107fe787ud342a3f99f6651ee@mail.gmail.com>

Of course, it's all my fault.
First, for having used a symbol that libc implementers are likely to add.
Second, for actually asking glibc implementers to add that very symbol.
Third, for forgetting that this is an issue in openjdk6 as well.

Anyways, I intend to commit these patches to their respective forests:

http://cr.openjdk.java.net/~martin/webrevs/openjdk6/rename-execvpe/
http://cr.openjdk.java.net/~martin/webrevs/openjdk7/rename-execvpe/

As ever, we need a Sun bug (could Michael or Joe file it?):

Synopsis: Rename execvpe to avoid symbol clash with glibc 2.10.
Description:
glibc 2.10 added the long-awaited "missing link" function execvpe
(thank you!  No really!)
But the JDK already has a function of that name, which needs renaming,
to avoid a compile time failure in UNIXProcess_md.c
Evaluation: Yup

Thanks,

Martin

On Wed, Jul 29, 2009 at 08:24, Andrew John
Hughes<gnu_andrew at member.fsf.org> wrote:
> 2009/7/28 Martin Buchholz <martinrb at google.com>:
>> On Tue, Jul 28, 2009 at 06:08, Michael McMahon<Michael.McMahon at sun.com> wrote:
>>> Andrew John Hughes wrote:
>>>>
>>>> 2009/7/28 Michael McMahon <Michael.McMahon at sun.com>:
>>>>
>>>>>
>>>>> Andrew John Hughes wrote:
>>>>>
>>>>>>
>>>>>> 2009/7/9 Martin Buchholz <martinrb at google.com>:
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> rename-execvpe is the one I'm particularly concerned about. ?It's a
>>>> trivial patch, but without it, OpenJDK builds are going to start
>>>> failing as distros move to the new glibc (e.g. Fedora 12). ?It's
>>>> already an issue for users of Fedora rawhide.
>>>>
>>>
>>> Ok. Maybe we can push rename-execvpe and RESTARTABLE first.
>>
>> RESTARTABLE depends on vfork-exec, and I would not like to do
>> the work to reorder them.
>>
>> Changes to fork-exec are always high-risk,
>> and I would like to see some more testing on these
>> before committing to openjdk proper.
>> That could be done by having icedtea7 import them,
>> and by having Michael or another Sun person run them
>> through Sun testing.
>>
>> There are more changes to fork-exec to come,
>> although they will probably not affect the average Linux user's
>> experience.
>>
>> Michael and I have been doing other things the past few weeks.
>>
>> Martin
>>
>
> Sure, we can do some testing with IcedTea7 after the release for M4,
> which should be sometime in the next week or so.
>
> In the meantime, can you or me push the execvpe cleanup to the 6 and 7
> forests (tl presumably for 7)? ?Or is there a further issue there?
> You've not mentioned it in either reply.
>
> Joe, I assume this is okay for 6? ?Without it the build is broken on
> newer distributions.
>
> Thanks,
> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8
>


From Joe.Darcy at Sun.COM  Thu Jul 30 04:22:58 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Wed, 29 Jul 2009 21:22:58 -0700
Subject: execvpe and glibc 2.10
In-Reply-To: <1ccfd1c10907292039y107fe787ud342a3f99f6651ee@mail.gmail.com>
References: <1ccfd1c10907091407q1557c49s6338614925808a23@mail.gmail.com>
	<17c6771e0907280524t40a84dbem94e73030f93499e5@mail.gmail.com>
	<4A6EF28B.8040302@sun.com>
	<17c6771e0907280551t7ef565ebw22f6a2d102065de7@mail.gmail.com>
	<4A6EF847.3030709@sun.com>
	<1ccfd1c10907280747r11681293k232bab01aa78679@mail.gmail.com>
	<17c6771e0907290824h158a60f2m441890db7ed3120d@mail.gmail.com>
	<1ccfd1c10907292039y107fe787ud342a3f99f6651ee@mail.gmail.com>
Message-ID: <4A712022.5000001@sun.com>

Martin Buchholz wrote:
> Of course, it's all my fault.
> First, for having used a symbol that libc implementers are likely to add.
> Second, for actually asking glibc implementers to add that very symbol.
> Third, for forgetting that this is an issue in openjdk6 as well.
>
> Anyways, I intend to commit these patches to their respective forests:
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk6/rename-execvpe/
> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/rename-execvpe/
>
> As ever, we need a Sun bug (could Michael or Joe file it?):
>
> Synopsis: Rename execvpe to avoid symbol clash with glibc 2.10.
> Description:
> glibc 2.10 added the long-awaited "missing link" function execvpe
> (thank you!  No really!)
> But the JDK already has a function of that name, which needs renaming,
> to avoid a compile time failure in UNIXProcess_md.c
> Evaluation: Yup
>
> Thanks,
>   

I've filed bug 6866719 and I approve the fix going back into 7 and 
OpenJDK 6.

Cheers,

-Joe

> Martin
>
> On Wed, Jul 29, 2009 at 08:24, Andrew John
> Hughes<gnu_andrew at member.fsf.org> wrote:
>   
>> 2009/7/28 Martin Buchholz <martinrb at google.com>:
>>     
>>> On Tue, Jul 28, 2009 at 06:08, Michael McMahon<Michael.McMahon at sun.com> wrote:
>>>       
>>>> Andrew John Hughes wrote:
>>>>         
>>>>> 2009/7/28 Michael McMahon <Michael.McMahon at sun.com>:
>>>>>
>>>>>           
>>>>>> Andrew John Hughes wrote:
>>>>>>
>>>>>>             
>>>>>>> 2009/7/9 Martin Buchholz <martinrb at google.com>:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>> rename-execvpe is the one I'm particularly concerned about.  It's a
>>>>> trivial patch, but without it, OpenJDK builds are going to start
>>>>> failing as distros move to the new glibc (e.g. Fedora 12).  It's
>>>>> already an issue for users of Fedora rawhide.
>>>>>
>>>>>           
>>>> Ok. Maybe we can push rename-execvpe and RESTARTABLE first.
>>>>         
>>> RESTARTABLE depends on vfork-exec, and I would not like to do
>>> the work to reorder them.
>>>
>>> Changes to fork-exec are always high-risk,
>>> and I would like to see some more testing on these
>>> before committing to openjdk proper.
>>> That could be done by having icedtea7 import them,
>>> and by having Michael or another Sun person run them
>>> through Sun testing.
>>>
>>> There are more changes to fork-exec to come,
>>> although they will probably not affect the average Linux user's
>>> experience.
>>>
>>> Michael and I have been doing other things the past few weeks.
>>>
>>> Martin
>>>
>>>       
>> Sure, we can do some testing with IcedTea7 after the release for M4,
>> which should be sometime in the next week or so.
>>
>> In the meantime, can you or me push the execvpe cleanup to the 6 and 7
>> forests (tl presumably for 7)?  Or is there a further issue there?
>> You've not mentioned it in either reply.
>>
>> Joe, I assume this is okay for 6?  Without it the build is broken on
>> newer distributions.
>>
>> Thanks,
>> --
>> Andrew :-)
>>
>> Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>>
>>     



From martinrb at google.com  Thu Jul 30 05:20:41 2009
From: martinrb at google.com (martinrb at google.com)
Date: Thu, 30 Jul 2009 05:20:41 +0000
Subject: hg: jdk7/tl/jdk: 2 new changesets
Message-ID: <20090730052132.20279EBF6@hg.openjdk.java.net>

Changeset: bfd7abda8f79
Author:    jjb
Date:      2009-07-29 14:24 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bfd7abda8f79

6804124: Replace "modified mergesort" in java.util.Arrays.sort with timsort
Summary: Easy port of timsort from android
Reviewed-by: martin

! make/java/java/FILES_java.gmk
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/Collections.java
+ src/share/classes/java/util/ComparableTimSort.java
+ src/share/classes/java/util/TimSort.java
+ test/java/util/TimSort/ArrayBuilder.java
+ test/java/util/TimSort/README
+ test/java/util/TimSort/SortPerf.java
+ test/java/util/TimSort/Sorter.java

Changeset: 15a7df80058e
Author:    martin
Date:      2009-07-29 21:45 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/15a7df80058e

6866719: Rename execvpe to avoid symbol clash with glibc 2.10
Reviewed-by: darcy

! src/solaris/native/java/lang/UNIXProcess_md.c



From martinrb at google.com  Thu Jul 30 05:41:42 2009
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 29 Jul 2009 22:41:42 -0700
Subject: execvpe and glibc 2.10
In-Reply-To: <4A712022.5000001@sun.com>
References: <1ccfd1c10907091407q1557c49s6338614925808a23@mail.gmail.com>
	<17c6771e0907280524t40a84dbem94e73030f93499e5@mail.gmail.com>
	<4A6EF28B.8040302@sun.com>
	<17c6771e0907280551t7ef565ebw22f6a2d102065de7@mail.gmail.com>
	<4A6EF847.3030709@sun.com>
	<1ccfd1c10907280747r11681293k232bab01aa78679@mail.gmail.com>
	<17c6771e0907290824h158a60f2m441890db7ed3120d@mail.gmail.com>
	<1ccfd1c10907292039y107fe787ud342a3f99f6651ee@mail.gmail.com>
	<4A712022.5000001@sun.com>
Message-ID: <1ccfd1c10907292241g472c58f4wfd6d26b297867734@mail.gmail.com>

Joe, thanks for the review.

I've pushed fixes for this problem to openjdk6 and openjdk7/tl

Martin

On Wed, Jul 29, 2009 at 21:22, Joseph D. Darcy<Joe.Darcy at sun.com> wrote:
> Martin Buchholz wrote:
>>
>> Of course, it's all my fault.
>> First, for having used a symbol that libc implementers are likely to add.
>> Second, for actually asking glibc implementers to add that very symbol.
>> Third, for forgetting that this is an issue in openjdk6 as well.
>>
>> Anyways, I intend to commit these patches to their respective forests:
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk6/rename-execvpe/
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/rename-execvpe/
>>
>> As ever, we need a Sun bug (could Michael or Joe file it?):
>>
>> Synopsis: Rename execvpe to avoid symbol clash with glibc 2.10.
>> Description:
>> glibc 2.10 added the long-awaited "missing link" function execvpe
>> (thank you! ?No really!)
>> But the JDK already has a function of that name, which needs renaming,
>> to avoid a compile time failure in UNIXProcess_md.c
>> Evaluation: Yup
>>
>> Thanks,
>>
>
> I've filed bug 6866719 and I approve the fix going back into 7 and OpenJDK
> 6.
>
> Cheers,
>
> -Joe
>
>> Martin
>>
>> On Wed, Jul 29, 2009 at 08:24, Andrew John
>> Hughes<gnu_andrew at member.fsf.org> wrote:
>>
>>>
>>> 2009/7/28 Martin Buchholz <martinrb at google.com>:
>>>
>>>>
>>>> On Tue, Jul 28, 2009 at 06:08, Michael McMahon<Michael.McMahon at sun.com>
>>>> wrote:
>>>>
>>>>>
>>>>> Andrew John Hughes wrote:
>>>>>
>>>>>>
>>>>>> 2009/7/28 Michael McMahon <Michael.McMahon at sun.com>:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Andrew John Hughes wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 2009/7/9 Martin Buchholz <martinrb at google.com>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> rename-execvpe is the one I'm particularly concerned about. ?It's a
>>>>>> trivial patch, but without it, OpenJDK builds are going to start
>>>>>> failing as distros move to the new glibc (e.g. Fedora 12). ?It's
>>>>>> already an issue for users of Fedora rawhide.
>>>>>>
>>>>>>
>>>>>
>>>>> Ok. Maybe we can push rename-execvpe and RESTARTABLE first.
>>>>>
>>>>
>>>> RESTARTABLE depends on vfork-exec, and I would not like to do
>>>> the work to reorder them.
>>>>
>>>> Changes to fork-exec are always high-risk,
>>>> and I would like to see some more testing on these
>>>> before committing to openjdk proper.
>>>> That could be done by having icedtea7 import them,
>>>> and by having Michael or another Sun person run them
>>>> through Sun testing.
>>>>
>>>> There are more changes to fork-exec to come,
>>>> although they will probably not affect the average Linux user's
>>>> experience.
>>>>
>>>> Michael and I have been doing other things the past few weeks.
>>>>
>>>> Martin
>>>>
>>>>
>>>
>>> Sure, we can do some testing with IcedTea7 after the release for M4,
>>> which should be sometime in the next week or so.
>>>
>>> In the meantime, can you or me push the execvpe cleanup to the 6 and 7
>>> forests (tl presumably for 7)? ?Or is there a further issue there?
>>> You've not mentioned it in either reply.
>>>
>>> Joe, I assume this is okay for 6? ?Without it the build is broken on
>>> newer distributions.
>>>
>>> Thanks,
>>> --
>>> Andrew :-)
>>>
>>> Free Java Software Engineer
>>> Red Hat, Inc. (http://www.redhat.com)
>>>
>>> Support Free Java!
>>> Contribute to GNU Classpath and the OpenJDK
>>> http://www.gnu.org/software/classpath
>>> http://openjdk.java.net
>>>
>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8
>>>
>>>
>
>


From maurizio.cimadamore at sun.com  Thu Jul 30 09:36:50 2009
From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com)
Date: Thu, 30 Jul 2009 09:36:50 +0000
Subject: hg: jdk7/tl/langtools: 4 new changesets
Message-ID: <20090730093659.9B200EC55@hg.openjdk.java.net>

Changeset: 85fecace920b
Author:    mcimadamore
Date:      2009-07-30 10:29 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/85fecace920b

6827648: Extremely slow compilation time for visitor pattern code + generics
Summary: Javac unnecessarily recomputates type-substitutions multiple times
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/code/Symbol.java
! src/share/classes/com/sun/tools/javac/code/Types.java

Changeset: b1e027181dd4
Author:    mcimadamore
Date:      2009-07-30 10:30 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b1e027181dd4

6862608: rich diagnostic sometimes contain wrong type variable numbering
Summary: The rich formatter generates worng numbers for type-variables in where clauses
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
+ test/tools/javac/Diagnostics/6862608/T6862608a.java
+ test/tools/javac/Diagnostics/6862608/T6862608a.out
+ test/tools/javac/Diagnostics/6862608/T6862608b.java
+ test/tools/javac/Diagnostics/6862608/T6862608b.out

Changeset: dd5c51734ad9
Author:    mcimadamore
Date:      2009-07-30 10:30 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dd5c51734ad9

6864382: NPE in the rich formatter when processing an unattributed type-variable
Summary: Unattributed type variable should not be accessed by the rich formatter when emitting where clauses
Reviewed-by: jjg

! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
+ test/tools/javac/Diagnostics/6864382/T6864382.java
+ test/tools/javac/Diagnostics/6864382/T6864382.out

Changeset: 6d0add6ad778
Author:    mcimadamore
Date:      2009-07-30 10:30 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6d0add6ad778

6861837: JCK compilation failures
Summary: Type-annotations processing is accessing type info before they are available in MemberEnter
Reviewed-by: jjg
Contributed-by: mali at csail.mit.edu

! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java
! src/share/classes/com/sun/tools/javac/comp/TransTypes.java
! test/tools/javac/typeAnnotations/InnerClass.java



From Anthony.Petrov at Sun.COM  Thu Jul 30 10:24:29 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Thu, 30 Jul 2009 14:24:29 +0400
Subject: Review request #0: 6863566 (Java should support the
	freedesktop.org startup notification specification)
In-Reply-To: <9e89675b0907291210x2fa1f2cdt31f10fcf20d3ff8f@mail.gmail.com>
References: <4A702ED2.1040804@sun.com>
	<9e89675b0907291210x2fa1f2cdt31f10fcf20d3ff8f@mail.gmail.com>
Message-ID: <4A7174DD.3060801@sun.com>

On 07/29/2009 11:10 PM, Damjan Jovanovic wrote:
>> Damjan, have you by the way tested the fix with a GUI Java application that
>> does not display a top-level window, but rather creates a tray icon only?
>> Does the notification get correctly removed from the task bar in that case?
> 
> It doesn't :-(.

Then I suggest to call the removeStartupNotification() method in the 
handleMapNotifyEvent() instead of the xSetVisible(). In that case it 
should theoretically work fine with tray-icon-only applications also. 
Can you test it please?

--
best regards,
Anthony


From Joe.Darcy at Sun.COM  Thu Jul 30 14:07:20 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 30 Jul 2009 07:07:20 -0700
Subject: <AWT Dev> Review request #0: 6863566 (Java should support the
	freedesktop.org startup notification specification)
In-Reply-To: <271e55d20907290604v1966cbe3wc42701675e533b19@mail.gmail.com>
References: <4A702ED2.1040804@sun.com>
	<271e55d20907290604v1966cbe3wc42701675e533b19@mail.gmail.com>
Message-ID: <4A71A918.701@sun.com>

Oleg Sukhodolsky wrote:
> Hi,
>
> just a short question:
> do we really have to change the launcher?  Why we can not add the
> changes to AWT's native code (somewhere near LoadLibrary())?
>
>   

Yes, it would be preferable if the launcher did not change for this.

-Joe

> Oleg.
>
> On Wed, Jul 29, 2009 at 3:13 PM, Anthony Petrov<Anthony.Petrov at sun.com> wrote:
>   
>> Hello,
>>
>> Please review the fix contributed by Damjan Jovanovic:
>>
>> RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094
>>
>> webrev: http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.0/
>>
>> Since the patch includes changes to the src/solaris/bin/java_md.c, I'm
>> CC'ing Kumar and Core Libs alias to review the changes in that file.
>>
>>
>> Damjan, have you by the way tested the fix with a GUI Java application that
>> does not display a top-level window, but rather creates a tray icon only?
>> Does the notification get correctly removed from the task bar in that case?
>>
>> --
>> best regards,
>> Anthony
>>
>>     



From Joe.Darcy at Sun.COM  Thu Jul 30 14:18:25 2009
From: Joe.Darcy at Sun.COM (Joseph D. Darcy)
Date: Thu, 30 Jul 2009 07:18:25 -0700
Subject: execvpe and glibc 2.10
In-Reply-To: <1ccfd1c10907292241g472c58f4wfd6d26b297867734@mail.gmail.com>
References: <1ccfd1c10907091407q1557c49s6338614925808a23@mail.gmail.com>
	<17c6771e0907280524t40a84dbem94e73030f93499e5@mail.gmail.com>
	<4A6EF28B.8040302@sun.com>
	<17c6771e0907280551t7ef565ebw22f6a2d102065de7@mail.gmail.com>
	<4A6EF847.3030709@sun.com>
	<1ccfd1c10907280747r11681293k232bab01aa78679@mail.gmail.com>
	<17c6771e0907290824h158a60f2m441890db7ed3120d@mail.gmail.com>
	<1ccfd1c10907292039y107fe787ud342a3f99f6651ee@mail.gmail.com>
	<4A712022.5000001@sun.com>
	<1ccfd1c10907292241g472c58f4wfd6d26b297867734@mail.gmail.com>
Message-ID: <4A71ABB1.5010208@sun.com>

Martin Buchholz wrote:
> Joe, thanks for the review.
>   

Thanks for the fixes :-)

-Joe

> I've pushed fixes for this problem to openjdk6 and openjdk7/tl
>
> Martin
>
> On Wed, Jul 29, 2009 at 21:22, Joseph D. Darcy<Joe.Darcy at sun.com> wrote:
>   
>> Martin Buchholz wrote:
>>     
>>> Of course, it's all my fault.
>>> First, for having used a symbol that libc implementers are likely to add.
>>> Second, for actually asking glibc implementers to add that very symbol.
>>> Third, for forgetting that this is an issue in openjdk6 as well.
>>>
>>> Anyways, I intend to commit these patches to their respective forests:
>>>
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk6/rename-execvpe/
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/rename-execvpe/
>>>
>>> As ever, we need a Sun bug (could Michael or Joe file it?):
>>>
>>> Synopsis: Rename execvpe to avoid symbol clash with glibc 2.10.
>>> Description:
>>> glibc 2.10 added the long-awaited "missing link" function execvpe
>>> (thank you!  No really!)
>>> But the JDK already has a function of that name, which needs renaming,
>>> to avoid a compile time failure in UNIXProcess_md.c
>>> Evaluation: Yup
>>>
>>> Thanks,
>>>
>>>       
>> I've filed bug 6866719 and I approve the fix going back into 7 and OpenJDK
>> 6.
>>
>> Cheers,
>>
>> -Joe
>>
>>     
>>> Martin
>>>
>>> On Wed, Jul 29, 2009 at 08:24, Andrew John
>>> Hughes<gnu_andrew at member.fsf.org> wrote:
>>>
>>>       
>>>> 2009/7/28 Martin Buchholz <martinrb at google.com>:
>>>>
>>>>         
>>>>> On Tue, Jul 28, 2009 at 06:08, Michael McMahon<Michael.McMahon at sun.com>
>>>>> wrote:
>>>>>
>>>>>           
>>>>>> Andrew John Hughes wrote:
>>>>>>
>>>>>>             
>>>>>>> 2009/7/28 Michael McMahon <Michael.McMahon at sun.com>:
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>>> Andrew John Hughes wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>                 
>>>>>>>>> 2009/7/9 Martin Buchholz <martinrb at google.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> rename-execvpe is the one I'm particularly concerned about.  It's a
>>>>>>> trivial patch, but without it, OpenJDK builds are going to start
>>>>>>> failing as distros move to the new glibc (e.g. Fedora 12).  It's
>>>>>>> already an issue for users of Fedora rawhide.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> Ok. Maybe we can push rename-execvpe and RESTARTABLE first.
>>>>>>
>>>>>>             
>>>>> RESTARTABLE depends on vfork-exec, and I would not like to do
>>>>> the work to reorder them.
>>>>>
>>>>> Changes to fork-exec are always high-risk,
>>>>> and I would like to see some more testing on these
>>>>> before committing to openjdk proper.
>>>>> That could be done by having icedtea7 import them,
>>>>> and by having Michael or another Sun person run them
>>>>> through Sun testing.
>>>>>
>>>>> There are more changes to fork-exec to come,
>>>>> although they will probably not affect the average Linux user's
>>>>> experience.
>>>>>
>>>>> Michael and I have been doing other things the past few weeks.
>>>>>
>>>>> Martin
>>>>>
>>>>>
>>>>>           
>>>> Sure, we can do some testing with IcedTea7 after the release for M4,
>>>> which should be sometime in the next week or so.
>>>>
>>>> In the meantime, can you or me push the execvpe cleanup to the 6 and 7
>>>> forests (tl presumably for 7)?  Or is there a further issue there?
>>>> You've not mentioned it in either reply.
>>>>
>>>> Joe, I assume this is okay for 6?  Without it the build is broken on
>>>> newer distributions.
>>>>
>>>> Thanks,
>>>> --
>>>> Andrew :-)
>>>>
>>>> Free Java Software Engineer
>>>> Red Hat, Inc. (http://www.redhat.com)
>>>>
>>>> Support Free Java!
>>>> Contribute to GNU Classpath and the OpenJDK
>>>> http://www.gnu.org/software/classpath
>>>> http://openjdk.java.net
>>>>
>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8
>>>>
>>>>
>>>>         
>>     



From gnu_andrew at member.fsf.org  Thu Jul 30 14:25:25 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Thu, 30 Jul 2009 15:25:25 +0100
Subject: execvpe and glibc 2.10
In-Reply-To: <4A71ABB1.5010208@sun.com>
References: <1ccfd1c10907091407q1557c49s6338614925808a23@mail.gmail.com>
	<4A6EF28B.8040302@sun.com>
	<17c6771e0907280551t7ef565ebw22f6a2d102065de7@mail.gmail.com>
	<4A6EF847.3030709@sun.com>
	<1ccfd1c10907280747r11681293k232bab01aa78679@mail.gmail.com>
	<17c6771e0907290824h158a60f2m441890db7ed3120d@mail.gmail.com>
	<1ccfd1c10907292039y107fe787ud342a3f99f6651ee@mail.gmail.com>
	<4A712022.5000001@sun.com>
	<1ccfd1c10907292241g472c58f4wfd6d26b297867734@mail.gmail.com>
	<4A71ABB1.5010208@sun.com>
Message-ID: <17c6771e0907300725o2b591e44u6355fbfa5489415a@mail.gmail.com>

2009/7/30 Joseph D. Darcy <Joe.Darcy at sun.com>:
> Martin Buchholz wrote:
>>
>> Joe, thanks for the review.
>>
>
> Thanks for the fixes :-)
>
> -Joe
>
>> I've pushed fixes for this problem to openjdk6 and openjdk7/tl
>>
>> Martin
>>
>> On Wed, Jul 29, 2009 at 21:22, Joseph D. Darcy<Joe.Darcy at sun.com> wrote:
>>
>>>
>>> Martin Buchholz wrote:
>>>
>>>>
>>>> Of course, it's all my fault.
>>>> First, for having used a symbol that libc implementers are likely to
>>>> add.
>>>> Second, for actually asking glibc implementers to add that very symbol.
>>>> Third, for forgetting that this is an issue in openjdk6 as well.
>>>>
>>>> Anyways, I intend to commit these patches to their respective forests:
>>>>
>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk6/rename-execvpe/
>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk7/rename-execvpe/
>>>>
>>>> As ever, we need a Sun bug (could Michael or Joe file it?):
>>>>
>>>> Synopsis: Rename execvpe to avoid symbol clash with glibc 2.10.
>>>> Description:
>>>> glibc 2.10 added the long-awaited "missing link" function execvpe
>>>> (thank you! ?No really!)
>>>> But the JDK already has a function of that name, which needs renaming,
>>>> to avoid a compile time failure in UNIXProcess_md.c
>>>> Evaluation: Yup
>>>>
>>>> Thanks,
>>>>
>>>>
>>>
>>> I've filed bug 6866719 and I approve the fix going back into 7 and
>>> OpenJDK
>>> 6.
>>>
>>> Cheers,
>>>
>>> -Joe
>>>
>>>
>>>>
>>>> Martin
>>>>
>>>> On Wed, Jul 29, 2009 at 08:24, Andrew John
>>>> Hughes<gnu_andrew at member.fsf.org> wrote:
>>>>
>>>>
>>>>>
>>>>> 2009/7/28 Martin Buchholz <martinrb at google.com>:
>>>>>
>>>>>
>>>>>>
>>>>>> On Tue, Jul 28, 2009 at 06:08, Michael
>>>>>> McMahon<Michael.McMahon at sun.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Andrew John Hughes wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 2009/7/28 Michael McMahon <Michael.McMahon at sun.com>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Andrew John Hughes wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2009/7/9 Martin Buchholz <martinrb at google.com>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> rename-execvpe is the one I'm particularly concerned about. ?It's a
>>>>>>>> trivial patch, but without it, OpenJDK builds are going to start
>>>>>>>> failing as distros move to the new glibc (e.g. Fedora 12). ?It's
>>>>>>>> already an issue for users of Fedora rawhide.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Ok. Maybe we can push rename-execvpe and RESTARTABLE first.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> RESTARTABLE depends on vfork-exec, and I would not like to do
>>>>>> the work to reorder them.
>>>>>>
>>>>>> Changes to fork-exec are always high-risk,
>>>>>> and I would like to see some more testing on these
>>>>>> before committing to openjdk proper.
>>>>>> That could be done by having icedtea7 import them,
>>>>>> and by having Michael or another Sun person run them
>>>>>> through Sun testing.
>>>>>>
>>>>>> There are more changes to fork-exec to come,
>>>>>> although they will probably not affect the average Linux user's
>>>>>> experience.
>>>>>>
>>>>>> Michael and I have been doing other things the past few weeks.
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Sure, we can do some testing with IcedTea7 after the release for M4,
>>>>> which should be sometime in the next week or so.
>>>>>
>>>>> In the meantime, can you or me push the execvpe cleanup to the 6 and 7
>>>>> forests (tl presumably for 7)? ?Or is there a further issue there?
>>>>> You've not mentioned it in either reply.
>>>>>
>>>>> Joe, I assume this is okay for 6? ?Without it the build is broken on
>>>>> newer distributions.
>>>>>
>>>>> Thanks,
>>>>> --
>>>>> Andrew :-)
>>>>>
>>>>> Free Java Software Engineer
>>>>> Red Hat, Inc. (http://www.redhat.com)
>>>>>
>>>>> Support Free Java!
>>>>> Contribute to GNU Classpath and the OpenJDK
>>>>> http://www.gnu.org/software/classpath
>>>>> http://openjdk.java.net
>>>>>
>>>>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>>>>> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>

Thanks!
-- 
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8


From jonathan.gibbons at sun.com  Thu Jul 30 14:55:27 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 30 Jul 2009 14:55:27 +0000
Subject: hg: jdk7/tl/langtools: 6866657: add byteLength method to primary
	classfile types
Message-ID: <20090730145531.4033CECBC@hg.openjdk.java.net>

Changeset: 23505e6ea22d
Author:    jjg
Date:      2009-07-30 07:48 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/23505e6ea22d

6866657: add byteLength method to primary classfile types
Reviewed-by: mchung

! src/share/classes/com/sun/tools/classfile/AccessFlags.java
! src/share/classes/com/sun/tools/classfile/Attribute.java
! src/share/classes/com/sun/tools/classfile/Attributes.java
! src/share/classes/com/sun/tools/classfile/ClassFile.java
! src/share/classes/com/sun/tools/classfile/ConstantPool.java
! src/share/classes/com/sun/tools/classfile/Field.java
! src/share/classes/com/sun/tools/classfile/Method.java
+ test/tools/javap/T6866657.java



From jonathan.gibbons at sun.com  Thu Jul 30 16:26:35 2009
From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com)
Date: Thu, 30 Jul 2009 16:26:35 +0000
Subject: hg: jdk7/tl/langtools: 4880672: javap does not output inner
	interfaces of an interface
Message-ID: <20090730162639.60B1CECD3@hg.openjdk.java.net>

Changeset: e33efb09ed75
Author:    jjg
Date:      2009-07-30 09:18 -0700
URL:       http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e33efb09ed75

4880672: javap does not output inner interfaces of an interface
Reviewed-by: mcimadamore

! src/share/classes/com/sun/tools/javap/JavapTask.java
! src/share/classes/com/sun/tools/javap/Options.java
! src/share/classes/com/sun/tools/javap/resources/javap.properties
+ test/tools/javap/T4880672.java



From weijun.wang at sun.com  Fri Jul 31 08:28:53 2009
From: weijun.wang at sun.com (weijun.wang at sun.com)
Date: Fri, 31 Jul 2009 08:28:53 +0000
Subject: hg: jdk7/tl/jdk: 6867231: Regression:
	jdk/test/sun/security/krb5/ConfPlusProp.java error against
	jdk7/pit/b68
Message-ID: <20090731082922.1E9D7EE10@hg.openjdk.java.net>

Changeset: 0c58a7b6b978
Author:    weijun
Date:      2009-07-31 16:21 +0800
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0c58a7b6b978

6867231: Regression: jdk/test/sun/security/krb5/ConfPlusProp.java error against jdk7/pit/b68
Reviewed-by: xuelei

! test/sun/security/krb5/ConfPlusProp.java



From Anthony.Petrov at Sun.COM  Fri Jul 31 10:34:36 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Fri, 31 Jul 2009 14:34:36 +0400
Subject: <AWT Dev> Review request #0: 6863566 (Java should support	the
	freedesktop.org startup notification specification)
In-Reply-To: <4A7174DD.3060801@sun.com>
References: <4A702ED2.1040804@sun.com>
	<9e89675b0907291210x2fa1f2cdt31f10fcf20d3ff8f@mail.gmail.com>
	<4A7174DD.3060801@sun.com>
Message-ID: <4A72C8BC.6010902@sun.com>

Hi Damjan,

On 07/30/2009 02:24 PM, Anthony Petrov wrote:
>>> Damjan, have you by the way tested the fix with a GUI Java 
>>> application that
>>> does not display a top-level window, but rather creates a tray icon 
>>> only?
>>> Does the notification get correctly removed from the task bar in that 
>>> case?
>>
>> It doesn't :-(.
> 
> Then I suggest to call the removeStartupNotification() method in the 
> handleMapNotifyEvent() instead of the xSetVisible(). In that case it 
> should theoretically work fine with tray-icon-only applications also. 
> Can you test it please?

By the way, since we care about displaying top-level windows only, then 
perhaps we can move the code to the XWindowPeer instead of the XBaseWindow?

--
best regards,
Anthony


From alan.bateman at sun.com  Fri Jul 31 18:33:43 2009
From: alan.bateman at sun.com (alan.bateman at sun.com)
Date: Fri, 31 Jul 2009 18:33:43 +0000
Subject: hg: jdk7/tl/jdk: 3 new changesets
Message-ID: <20090731183502.A635DEE74@hg.openjdk.java.net>

Changeset: e2d9696aa701
Author:    alanb
Date:      2009-07-31 08:44 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e2d9696aa701

6867101: Path.checkAccess fails with sharing violation on special files such as pagefile.sys
Reviewed-by: sherman

! src/windows/classes/sun/nio/fs/WindowsConstants.java
! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java
! test/java/nio/file/Path/Misc.java

Changeset: d5ee8b871362
Author:    alanb
Date:      2009-07-31 08:45 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d5ee8b871362

6867244: Tests missing @run tag
Reviewed-by: sherman

! test/java/nio/channels/DatagramChannel/BasicMulticastTests.java
! test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java
! test/java/nio/file/Files/ContentType.java

Changeset: 160e02039cf7
Author:    alanb
Date:      2009-07-31 19:23 +0100
URL:       http://hg.openjdk.java.net/jdk7/tl/jdk/rev/160e02039cf7

Merge




From Alan.Bateman at Sun.COM  Fri Jul 31 19:07:11 2009
From: Alan.Bateman at Sun.COM (Alan Bateman)
Date: Fri, 31 Jul 2009 20:07:11 +0100
Subject: Review quest for 6595866: File does work with symbolic links
	(win,vista)
Message-ID: <4A7340DF.60408@sun.com>

Sherman, you'll probably want to take this one.

Windows Vista brought symbolic links to NTFS and they work well with the 
new file system API. This patch makes a start on fixing the issues with 
java.io.File when it encounters these alien creatures on a dark night. 
Specifically, it fixes the code used by the length, lastModified, 
exists, isXXX, canXXX, and setXXX methods so that the links work 
transparently. Currently these methods are using Win32 APIs that don't 
do reparse point processing and so do not access the attributes of the 
final target as expected. The other main issue fixed by this patch is to 
the createNewFile method so that it returns false when there is an 
existing file that is a symbolic link. One remaining issue that isn't 
addressed by this patch is canonicalization. That's a meal in itself and 
patch for another day.

In terms of compatibility, the only behavior change for pre-Vista 
(meaning XP and Windows Server 2003) is that the setReadOnly, 
setReadable and setWritable methods will fail if the File represents a 
path to a file that is a reparse point. I'm not too worried about that 
because they are so rare, and the methods do the wrong thing anyway.

Here's the webrev:
  http://cr.openjdk.java.net/~alanb/6595866/webrev.00/

Thanks,

Alan.