I'd like to revive this review thread.
Updated version:
http://cr.openjdk.java.net/~vlivanov/8037209/webrev.04/
Paul, I'd like to address your case (if possible) separately. Right now,
I don't see any way to avoid null check you see with your tests.
Best regards,
Vladimir Ivanov
On 3/24/14
I'd like to revive review this review thread.
Updated version:
http://cr.openjdk.java.net/~vlivanov/8038261/webrev.03/
Thanks!
Best regards,
Vladimir Ivanov
On 3/24/14 10:10 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8038261/webrev.00
On 07/08/2014 09:33 AM, Martin Buchholz wrote:
I've updated the webrev
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/
It now has all my TODOs done.
The test case has been testng-ified.
Hi Martin,
What happened to the desire that when OOME is thrown on resizing,
On Jul 8, 2014, at 12:09 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
I'd like to revive review this review thread.
Updated version:
http://cr.openjdk.java.net/~vlivanov/8038261/webrev.03/
+1
Paul.
On 07/08/2014 12:12 PM, Peter Levart wrote:
On 07/08/2014 09:33 AM, Martin Buchholz wrote:
I've updated the webrev
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/
It now has all my TODOs done.
The test case has been testng-ified.
Hi Martin,
What happened to
On Jul 8, 2014, at 12:40 PM, Paul Sandoz paul.san...@oracle.com wrote:
On Jul 8, 2014, at 12:09 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
I'd like to revive review this review thread.
Updated version:
http://cr.openjdk.java.net/~vlivanov/8038261/webrev.03/
+1
A
On Jul 8, 2014, at 12:09 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
I'd like to revive this review thread.
Updated version:
http://cr.openjdk.java.net/~vlivanov/8037209/webrev.04/
Seems ok. I don't claim to be knowledgable enough in the finer points of
Hi again,
Here's a version with (3*size len) replaced with (size len/3) as
suggested by Ivan Gerasimov to avoid overflow and also fixed if block if
put() that enclosed too much code (in my changed version of Martin's
latest webrev):
I'd like to revive review this review thread.
Updated version:
http://cr.openjdk.java.net/~vlivanov/8038261/webrev.03/
+1
A v. minor point. There is one newly added method
InvokerBytecodeGenerator.match that is not used by this patch or the other one
for 8037209. I dunno if it will be used
On 08.07.2014 15:25, Peter Levart wrote:
Hi again,
Here's a version with (3*size len) replaced with (size len/3) as
suggested by Ivan Gerasimov to avoid overflow and also fixed if block
if put() that enclosed too much code (in my changed version of
Martin's latest webrev):
It shouldn't
On 07/08/2014 01:53 PM, Ivan Gerasimov wrote:
On 08.07.2014 15:25, Peter Levart wrote:
Hi again,
Here's a version with (3*size len) replaced with (size len/3) as
suggested by Ivan Gerasimov to avoid overflow and also fixed if block
if put() that enclosed too much code (in my changed
On 8/07/2014 5:25 AM, Ivan Gerasimov wrote:
Thanks you Sherman for review!
On 07.07.2014 21:38, Xueming Shen wrote:
On 07/07/2014 10:07 AM, Ivan Gerasimov wrote:
Hello!
The javadoc says that Pattern.compile(String regex, int flag) will
throw IllegalArgumentException, if flag contains an
On 07/08/2014 02:20 PM, Peter Levart wrote:
That's right. Not in put(). But in putAll() it can overflow, since the
argument Map can be of any size that fits in int... So here's my 3rd
variation of Martin's latest version:
http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.03/
Hi,
Please find below a fix for
8048913: java/util/logging/LoggingDeadlock2.java times out
http://cr.openjdk.java.net/~dfuchs/webrev_8048913/webrev.00/
jdk/test/java/util/logging/LoggingDeadlock2.java has been seen failing
in timeout in some of our internal nightly builds.
On 08.07.2014 4:44, Martin Buchholz wrote:
On Mon, Jul 7, 2014 at 9:41 AM, Martin Buchholz marti...@google.com
mailto:marti...@google.com wrote:
I'd like to offer an alternative version of this change. webrev
coming soon.
Here's the promised webrev.
I took out the special case for javax.jnlp and follow up the change in
deploy to use @jdk.Exported to indicate its supportedness. I also added
a new test case to check the dot file output:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.01
thanks
Mandy
On 6/25/14 1:21 PM,
On 07/08/2014 03:00 PM, Ivan Gerasimov wrote:
I took your latest version of the patch and modified it a little:
http://cr.openjdk.java.net/~plevart/jdk9-dev/IdentityHashMap/webrev.01/
But isn't it post-insert-resize vs pre-insert-resize problem Doug
mentioned above?
I've tested a similar
On 07/08/2014 03:56 PM, Martin Buchholz wrote:
On Tue, Jul 8, 2014 at 5:30 AM, Peter Levart peter.lev...@gmail.com wrote:
On 07/08/2014 02:20 PM, Peter Levart wrote:
That's right. Not in put(). But in putAll() it can overflow, since the
argument Map can be of any size that fits in int...
Hi Mandy,
On 7/8/14 4:59 PM, Mandy Chung wrote:
I took out the special case for javax.jnlp and follow up the change in
deploy to use @jdk.Exported to indicate its supportedness. I also added
a new test case to check the dot file output:
Is anyone else seeing the following timeout? I had this issue last week and
thought it might have been a hiccup on the systems but trying again today and
the same error:
hg pull
pulling from http://hg.openjdk.java.net/jdk9/dev/jdk
searching for changes
adding changesets
adding manifests
Hello,
A comment on a ccc request for this kind of change below...
On 07/08/2014 05:25 AM, David Holmes wrote:
On 8/07/2014 5:25 AM, Ivan Gerasimov wrote:
Thanks you Sherman for review!
On 07.07.2014 21:38, Xueming Shen wrote:
On 07/07/2014 10:07 AM, Ivan Gerasimov wrote:
Hello!
The
Thanks Daniel.
Mandy
On 7/8/14 8:21 AM, Daniel Fuchs wrote:
Hi Mandy,
On 7/8/14 4:59 PM, Mandy Chung wrote:
I took out the special case for javax.jnlp and follow up the change in
deploy to use @jdk.Exported to indicate its supportedness. I also added
a new test case to check the dot file
Given the table size if a power of two, another possible optimization
would be
private static int nextKeyIndex(int i, int len) {
-return (i + 2 len ? i + 2 : 0);
+return (i + 2) (len - 1);
}
Or even
+int m = len - 1;
while ( (item = tab[i]) != null)
Regarding the extra cast in accessor logic that Paul picked up on: That may be
a left-over from obsolete versions of the code, or it may cover for some corner
cases, or it could possibly be a re-assurance to the JIT.
Generally speaking, we lean heavily on MH types to guarantee a priori
Please review the fix for JDK-8049373. It applies only to 8u.
The JBS issue is not public, but the general problem is that some closed
changes related to JDK-8044473 incorrectly ended up being added to the
compact 1 profile. The changes in question depend on the management
APIs, which are
In my opinion, there are two issues here,
the first one is the extra Class.cast which is inserted and as John said
it should be interesting to try to remove them.
the second one is why when there is a Class.cast, the cast is
effectively removed but a null check stay.
regards,
Rémi
On
Looks okay.
Mandy
On 7/8/14 12:15 PM, Brent Christian wrote:
Please review the fix for JDK-8049373. It applies only to 8u.
The JBS issue is not public, but the general problem is that some
closed changes related to JDK-8044473 incorrectly ended up being added
to the compact 1 profile. The
On 07/08/2014 10:07 PM, Martin Buchholz wrote:
I updated my webrev and it is again feature-complete.
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/
http://cr.openjdk.java.net/%7Emartin/webrevs/openjdk9/IdentityHashMap-capacity/
(old webrev at
If size == MAXIMUM_CAPACITY - 1 and you're in resize, presumably you're
about to fill that last empty slot after returning, so you want to throw
instead of returning false?
Benchmarks welcome.
On Tue, Jul 8, 2014 at 2:15 PM, Peter Levart peter.lev...@gmail.com wrote:
On 07/08/2014 10:07 PM,
Might be worth to add modCount++ before this line:
487 table = newTable;
488 return true;
On 09.07.2014 0:07, Martin Buchholz wrote:
I updated my webrev and it is again feature-complete.
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/IdentityHashMap-capacity/
On 07/08/2014 11:39 PM, Ivan Gerasimov wrote:
Might be worth to add modCount++ before this line:
487 table = newTable;
488 return true;
Not quite, I think. The map has just been resized, but it's contents has
not changed yet logically.
Regards, Peter
On 09.07.2014
Looks pretty good. I like the additional comments as well.
Could you document the return conditions of resize()?
A since we're there already suggestion for readObject:
if (size 0)
throw new InvalidObjectException(Illegal mappings count: + size);
Mike
On Jul 8 2014, at 13:07 , Martin
On 09.07.2014 1:44, Peter Levart wrote:
On 07/08/2014 11:39 PM, Ivan Gerasimov wrote:
Might be worth to add modCount++ before this line:
487 table = newTable;
488 return true;
Not quite, I think. The map has just been resized, but it's contents
has not changed yet
On 07/09/2014 12:06 AM, Ivan Gerasimov wrote:
On 09.07.2014 1:44, Peter Levart wrote:
On 07/08/2014 11:39 PM, Ivan Gerasimov wrote:
Might be worth to add modCount++ before this line:
487 table = newTable;
488 return true;
Not quite, I think. The map has just been
Ah, yes, sure.
I overlooked the reference to the table :-)
On 09.07.2014 2:42, Peter Levart wrote:
On 07/09/2014 12:06 AM, Ivan Gerasimov wrote:
On 09.07.2014 1:44, Peter Levart wrote:
On 07/08/2014 11:39 PM, Ivan Gerasimov wrote:
Might be worth to add modCount++ before this line:
487
On 09.07.2014 3:20, Martin Buchholz wrote:
I agree with Peter that we do not need to increment modCount on resize.
My latest webrev is again done.
Ivan, feel free to take over.
Yes, thanks! The fix is much much better now.
I think I see yet another very minor glitch, though.
If the table
Here's the same final webrev by Martin.
I only shortened the comment before capacity() and moved the check in
resize() upper.
http://cr.openjdk.java.net/~igerasim/6904367/4/webrev/
Sincerely yours,
Ivan
On 09.07.2014 4:25, Ivan Gerasimov wrote:
On 09.07.2014 3:20, Martin Buchholz wrote:
I
On 09.07.2014 4:46, Martin Buchholz wrote:
Let me understand - you're worried that when size is MAX_CAPACITY - 1,
then a call to putAll that does not actually add any elements might
throw? Well, I'm having a hard time considering that corner case a
bug, given how unusable the map is at this
Thanks Joe for the review. Would someone from deploy team have a quick
look so we can push this?
Cheers,
Henry
On 06/23/2014 06:03 PM, Joe Darcy wrote:
Hi Henry,
The changes look good to me; thanks,
-Joe
On 06/23/2014 05:31 PM, Henry Jen wrote:
Hi,
Please review another webrev to clean
Hi,
Would someone from swing team care to take a look at this?
The change of src/macosx/classes/sun/font/CFontConfiguration.java will
be dropped as it had been fixed in JDK-8048980.
Cheers,
Henry
On 06/27/2014 03:00 PM, Joe Darcy wrote:
Hi Henry,
Your changes look good to me (I assume
On 7/8/2014 5:58 AM, Daniel Fuchs wrote:
Hi,
Please find below a fix for
8048913: java/util/logging/LoggingDeadlock2.java times out
http://cr.openjdk.java.net/~dfuchs/webrev_8048913/webrev.00/
My suggestion is thus simply to remove the /timeout=15 from the
@run command line, relying
On 8/07/2014 10:58 PM, Daniel Fuchs wrote:
Hi,
Please find below a fix for
8048913: java/util/logging/LoggingDeadlock2.java times out
http://cr.openjdk.java.net/~dfuchs/webrev_8048913/webrev.00/
jdk/test/java/util/logging/LoggingDeadlock2.java has been seen failing
in timeout in some of our
Thanks for the response, Mandy. I'm looking forward to seeing the final
version.
For CallerFinder, we use reflective goop to get at
sun.misc.JavaLangAccess.getStackTraceElement. It requires us to build a
Throwable (with associated stacktrace), but not to generate all of those
43 matches
Mail list logo
