Changeset: cbcd9b484759
Author:vromero
Date: 2013-01-27 19:38 +
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cbcd9b484759
8006944: javac, combo tests should print out the number of threads used
Reviewed-by: mcimadamore
! test/tools/javac/lib/JavacTestingAbstractThreade
As part of JEP 155 (Concurrency Updates) we are proposing to add
StampedLock. A capability-based lock with three modes for controlling
read/write access.
Javadoc:
http://cr.openjdk.java.net/~chegar/8005697/ver.00/javadoc/StampedLock.html
(some external links are not working in this online ve
On 26/01/2013 17:14, Martin Buchholz wrote:
:
Following up on this, I have a simple webrev:
http://cr.openjdk.java.net/~martin/webrevs/openjdk8/LARGEFILE/
with an "obviously correct" fix. However:
- we need a bug filed
- This change is completely untested. I no longer have access to native
3
On 25/01/2013 17:55, Peter Levart wrote:
:
The solution is actually very simple. I just want to validate my
reasoning before jumping to implement it:
- for solving scalability of getProxyClass cache, a field with a
reference to ConcurrentHashMap, Class>
is added to j.l.ClassLoader
- for so
On 01/28/2013 03:32 PM, Chris Hegarty wrote:
> StampedLock, as usual, is coming from Doug Lea, with assistance from
> members of the former JCP JSR-166 Expert Group. Aleksey Shipilev, Dave
> Dice, and I, have all informally reviewed this, and our feedback is
> already incorporated in this version.
On 01/28/2013 03:32 PM, Chris Hegarty wrote:
> Webrev:
> http://cr.openjdk.java.net/~chegar/8005697/ver.00/webrev/webrev/
The only nit I find unlucky is that we need to duplicate the TLR code in
LockSupport. It looks like we would be better off with the helper class
sharing this functionality. I
On 01/28/13 07:16, Aleksey Shipilev wrote:
On 01/28/2013 03:32 PM, Chris Hegarty wrote:
Webrev:
http://cr.openjdk.java.net/~chegar/8005697/ver.00/webrev/webrev/
The only nit I find unlucky is that we need to duplicate the TLR code in
LockSupport. It looks like we would be better off with th
On 01/28/2013 12:49 PM, Alan Bateman wrote:
On 25/01/2013 17:55, Peter Levart wrote:
:
The solution is actually very simple. I just want to validate my
reasoning before jumping to implement it:
- for solving scalability of getProxyClass cache, a field with a
reference to ConcurrentHashMap,
On 1/25/2013 9:39 AM, Eric McCorkle wrote:
Thanks for the input, everyone.
I take it this is ok to push, then?
Looks good to me. Thank you for doing this.
Coleen
On 01/25/13 06:22, Alan Bateman wrote:
On 24/01/2013 20:29, Eric McCorkle wrote:
Also, can someone more experienced in core-li
On 01/28/2013 01:22 PM, Doug Lea wrote:
On 01/28/13 07:16, Aleksey Shipilev wrote:
On 01/28/2013 03:32 PM, Chris Hegarty wrote:
Webrev:
http://cr.openjdk.java.net/~chegar/8005697/ver.00/webrev/webrev/
The only nit I find unlucky is that we need to duplicate the TLR code in
LockSupport. It loo
On 01/26/13 02:52, David Holmes wrote:
> There must already be tests for this new feature else you would be
> pushing untested code, so you would break these tests while your changes
> sync up.
>
Tests do exist, but they are presently disabled. The end-to-end tests
were part of JDK-8004729, whic
Hi Alan,
I prepared the variant with lazy initialization of ConcurrentHashMaps
per ClassLoader and performance measurements show no differences. So
here's this variant:
* http://dl.dropbox.com/u/101777488/jdk8-tl/proxy/webrev.03/index.html
I also checked the ClassLoader layout and as it happ
Hi Alan,
On 01/25/2013 06:53 AM, Alan Bateman wrote:
Dan,
I've taken a pass over this and overall this is good clean-up and
something that was just not possible before jdk8 because of the need
to keep -XX:+UseVMInterruptibleIO working on Solaris.
A few comments:
- I don't understand why th
On Jan 26, 2013, at 4:50 AM, Chris Hegarty wrote:
>> To be clear I'm not saying this can't happen. I'm just saying that the right
>> people need to ensure that all the necessary pieces are in place, and the
>> procedures established before we actually start doing it on a regular basis.
>
> Yes,
On 01/28/13 06:32, Chris Hegarty wrote:
As part of JEP 155 (Concurrency Updates) we are proposing to add StampedLock. A
capability-based lock with three modes for controlling read/write access.
Javadoc:
http://cr.openjdk.java.net/~chegar/8005697/ver.00/javadoc/StampedLock.html
(some external
On Jan 21, 2013, at 3:12 AM, Aleksey Shipilev
wrote:
>
> Ok, now as this is being taken care of, you need to follow these steps:
>
> a) prepare the code, and create the webrev [1] for the change.
>
> b) upload the webrev somewhere, submit the link to webrev for formal
> review on this list, c
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006627
I have created a patch that dramatically improves UUID to/from string
performance.
Please find below a webrev with my proposed changes.
Thanks in advance for any feedback on the contents.
I do not believe I have a committer lined up yet.
Looks good for me.
You can add me as reviewer for the push.
Regards,
-uta
On 28.01.2013 19:38, Rob McKenna wrote:
Can I take this as your final approval? (also, does this apply to the
closed review?)
Thanks,
-Rob
On 25/01/13 20:43, Rob McKenna wrote:
Yup, all affected tests pass in bot
18 matches
Mail list logo