Hello Mandy,
Looks good. Just noticed another thing in CheckModules.gmk. You can
remove the explicit FIXPATH as the variable JAVA already contains it. In
general, only spec.gmk should need to worry about FIXPATH.
If there are no other changes, I don't need to see another round before
you
So it's not that the optimization fails but there is no optimization on them
yet.
I do see the .append(x) case will be easy to deal with, but it looks like
historically javac has not been a place to do many optimizations. It mostly
converts the java source to byte codes in a 1-to-1 mapping and
On 28/08/2014 08:31, Michael Kay wrote:
I haven't yet had a chance to look at the JAXP tests, but this kind of message suggests
to me that they don't separate what is in JAXP (the interface) from what is in Xalan and
Xerces (the implementations).Would that be a correct assumption? The
Hi,
Please review fixes by Doug to j.u.c.CompletableFuture to better control
resources for long completion chains (e.g. avoiding stack overflows). This fix
resulted in a lot of internal refactoring and clean up. There are also some
doc clarifications for certain j.u.c.CompletationStage
Hi,
Please review fixes by Doug to For/Join to improve thread throttling (e.g. for
nested parallel streams). This fix resulted in a lot of internal refactoring
and clean up.
In addition a new system property was added
java.util.concurrent.ForkJoinPool.common.maximumSpares (which i suspect
On 28/08/2014 23:28, Ivan Gerasimov wrote:
Hello!
This is a proposal to make some minor cleanup in WinNTFileSystem_md.c:
- fix a typo in error message,
Looks okay.
- use wide char constant for consistency,
Looks okay.
- avoid an array reallocation for power-of-two sizes,
It's a bit of
Hi Andrej,
On 22 jun 2014, at 00:00, Andrej Golovnin andrej.golov...@gmail.com wrote:
Hi Joel,
sorry for late response. I was too busy with other things.
Likewise!
I have changed the test TestMethodReflectValueOf as you suggested and I have
changed the summary of both tests too. You
On 08/29/2014 06:01 AM, Paul Sandoz wrote:
Hi,
Please review fixes by Doug to j.u.c.CompletableFuture to better control
resources for long completion chains (e.g. avoiding stack overflows). This fix
resulted in a lot of internal refactoring and clean up. There are also some
doc
On 29/08/14 11:01, Paul Sandoz wrote:
Hi,
Please review fixes by Doug to j.u.c.CompletableFuture to better control
resources for long completion chains (e.g. avoiding stack overflows). This fix
resulted in a lot of internal refactoring and clean up. There are also some
doc clarifications
On Aug 29, 2014, at 3:35 PM, Doug Lea d...@cs.oswego.edu wrote:
Is the following snippet missing from the doc updates to the methods
CompletationStage.handle and handleAsync?
While touching up wording, we noticed that this sentence doesn't capture
all the cases that are described in the
On Aug 29, 2014, at 3:38 PM, Chris Hegarty chris.hega...@oracle.com wrote:
On 29/08/14 11:01, Paul Sandoz wrote:
Hi,
Please review fixes by Doug to j.u.c.CompletableFuture to better control
resources for long completion chains (e.g. avoiding stack overflows). This
fix resulted in a
ArrayListString list = ...
iterator.forEachRemaining(list::add);
Rémi
On 29 août 2014 00:22:11 UTC+02:00, Pavel Rappo pavel.ra...@oracle.com wrote:
If we were to provide a Collections util it would to wrap Enumeration
as an Iterator but that's it.
Mike, that's what I'm talking about. It's just
On Aug 29, 2014, at 12:45 AM, John Rose john.r.r...@oracle.com wrote:
On Aug 28, 2014, at 7:38 AM, Paul Sandoz paul.san...@oracle.com wrote:
On Jul 8, 2014, at 9:09 PM, John Rose john.r.r...@oracle.com wrote:
Regarding the extra cast in accessor logic that Paul picked up on: That
may
Hi Joel,
I have changed the test TestMethodReflectValueOf as you suggested and I have
changed the summary of both tests too. You will find the changes in the
attached patch. Here is the new webrev: https://db.tt/wQBLVceA
And here is the coverage report in the HTML format:
Looks fine.
Instead of using Contributed-by: for Doug's work, you should make him the
hg user, as is done in previous changesets. E.g. hg import has a --user
flag.
All of jsr166 CVS src/main is ready for sync'ing with openjdk9, i.e. there
are no known bugs, even though some future improvements
Approved. Thanks for doing this.
On Fri, Aug 29, 2014 at 3:43 AM, Paul Sandoz paul.san...@oracle.com wrote:
Hi,
Please review fixes by Doug to For/Join to improve thread throttling (e.g.
for nested parallel streams). This fix resulted in a lot of internal
refactoring and clean up.
In
Hi Joe,
This looks OK. I assume all TCK/JCK tests have been run and still pass as an
additional sanity check ?
Have a good weekend.
Best,
Lance
On Aug 26, 2014, at 1:41 PM, huizhe wang huizhe.w...@oracle.com wrote:
Hi,
Please review update to XMLSchemaFactory along with changes to
Hi Joe, Alan and others
I took over Eric’s last work and did some refactor for his code. Please help to
review the code change again.
webrev: http://cr.openjdk.java.net/~tyan/JDK-8051561/webrev.01/
http://cr.openjdk.java.net/~tyan/JDK-8051561/webrev.01/
bug:
http://cr.openjdk.java.net/~vlivanov/8056926/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8056926
Cache GuardWithTest per erased to basic types signature.
GWT shape is made friendly to sharing:
* GWT MH is implemented as BMH which stores 3 method handles
* LF loads them from the
Hi Tristan,
Looks good. I left notes in the bug's comment section as a record and
status of the original test development.
Thanks,
Joe
On 8/29/2014 9:50 AM, Tristan Yan wrote:
Hi Joe, Alan and others
I took over Eric’s last work and did some refactor for his code.
Please help to review the
Am 28.08.2014 um 19:30 schrieb Louis Wasserman:
Comparator is spec'd to be allowed to return any number, positive, negative, or zero, but indexOf
is specifically spec'd to return -1.
Yes, I know. I wanted to say, that from this knowing some developer might assume the same for
indexOf when
On 29 Aug 2014, at 16:56, Martin Buchholz marti...@google.com wrote:
Looks fine.
+1
-Chris.
Instead of using Contributed-by: for Doug's work, you should make him the
hg user, as is done in previous changesets. E.g. hg import has a --user
flag.
All of jsr166 CVS src/main is ready for
Yes, the immediate is part of the instruction encoding, so takes up space.
However, I believe the CMP instruction allows comparison of an immediate
with a wider register (e.g. cmp $-1, %eax), in which case the immediate
takes up 1 byte and is then sign extended to the size of the register.
But
Just think - one whole byte saved for each individual change!
I have a webrev!
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/pico-optimize-contains/
https://bugs.openjdk.java.net/browse/JDK-8056951
Can haz review please?
On Fri, Aug 29, 2014 at 1:05 PM, Ulf Zibis ulf.zi...@cosoco.de
It's probably best to teach the JIT to handle more of these cases. The
reason is I don't think the longer compile time will be worth it
considering that, on a large codebase, there will inevitably be lots of
places where these patterns appear but have no dominance at runtime (either
because
:) so if you're going to do this, is there no base class in the hierarchy
where this can be placed (I don't have source in front of me)? That way
there's a higher likelihood that the pattern will stay consistent (with new
implementations at least).
Sent from my phone
On Aug 29, 2014 5:56 PM,
Bug: https://bugs.openjdk.java.net/browse/JDK-8046070
jdk9 review thread:
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-August/012235.html
jdk9 webrev: http://cr.openjdk.java.net/~iklam/8046070-cds-cleanup-vfinal/
jdk8u-40 webrev:
On Aug 29, 2014, at 1:05 PM, Ulf Zibis ulf.zi...@cosoco.de wrote:
Thanks for explaining this, but a very little nit: the immediate (I.e. -1)
uses additional 32/64 bits in code which must be loaded from memory and
wastes space in CPU cache or am I wrong? This could be saved with = 0.
I have
I decided to care just enough about the last 2x of scalability, but not
about the last 8 elements.
Your code would resize the 2g elements 8 times before finally reaching
MAX_VALUE...
Now I'm back in not-caring-anymore mode.
At least about MAX_ARRAY_SIZE.
On Wed, Aug 27, 2014 at 3:41 AM, Ulf
Hi John,
I agree that the benefit is very small, but I am coming at this from source
code consistency and bytecode size (not jitted code performance), and I
think bytecode size is at least one of the problems with assert.
...
I filed that bug long ago, but no action yet
On Aug 29, 2014, at 5:27 PM, Martin Buchholz marti...@google.com wrote:
I agree that the benefit is very small, but I am coming at this from source
code consistency and bytecode size (not jitted code performance), and I think
bytecode size is at least one of the problems with assert.
We
31 matches
Mail list logo
