On 1/12/17 11:14 AM, Hamlin Li wrote:
Need to update the year in copyright, it's new year 2017, I guess lot
of us do not notice it.
Thank you. Fixed :-)
Thanks,
Amy
Thank you
-Hamlin
On 2017/1/11 18:14, Amy Lu wrote:
On 12/23/16 8:54 AM, Amy Lu wrote:
On 12/20/16 8:04 PM, Wang Weijun wrote
Would you please review the below patch?
bug: https://bugs.openjdk.java.net/browse/JDK-8030950
webrev: http://cr.openjdk.java.net/~mli/8030950/webrev.00/
Thank you
-Hamlin
Need to update the year in copyright, it's new year 2017, I guess lot of
us do not notice it.
Thank you
-Hamlin
On 2017/1/11 18:14, Amy Lu wrote:
On 12/23/16 8:54 AM, Amy Lu wrote:
On 12/20/16 8:04 PM, Wang Weijun wrote:
For the failing case, the first time it calls checkNames, the "ans"
(th
> On Jan 11, 2017, at 5:45 PM, Naoto Sato wrote:
>
> Decided to include the fix to 8171140 [1] as well, as they are closely
> related. Here is the updated webrev.
>
> http://cr.openjdk.java.net/~naoto/8171139.8171140/webrev.01/
>
> Additional changes to the version 00 are to mainly remove cle
> On 1/10/17 4:10 PM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes to the subject issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8171139
>>
>> The changes are located at:
>>
>> http://cr.openjdk.java.net/~naoto/8171139/webrev.00/
>>
622 CacheKey setName(String
Looks good!
On Wed, Jan 11, 2017 at 4:48 PM, Paul Sandoz wrote:
> Thanks.
>
> Here is an update:
>
> http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/
>
> With changes to inline expressions, remove thread group stuff from TLR,
> and do the following in InnocuousForkJoinWor
On 12/23/16 8:54 AM, Amy Lu wrote:
On 12/20/16 8:04 PM, Wang Weijun wrote:
For the failing case, the first time it calls checkNames, the "ans"
(the 3rd arg) is "current working dir" (/path/scratch/1).
Is it possible to use ./tmp as "ans"?
--Max
Yes, good idea.
Please review the updated webr
8135248 and 8155794 introduced utility methods for checking indexes and
ranges. Existing code with custom checkIndex/checkRange can be updated
to use these methods. Please review the patch for this purpose:
bug: https://bugs.openjdk.java.net/browse/JDK-8146668
webrev: http://cr.openjdk.java.net
Decided to include the fix to 8171140 [1] as well, as they are closely
related. Here is the updated webrev.
http://cr.openjdk.java.net/~naoto/8171139.8171140/webrev.01/
Additional changes to the version 00 are to mainly remove
clearCache(Module) method, as clearCache() is chiefly used in
comb
Thanks.
Here is an update:
http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/
With changes to inline expressions, remove thread group stuff from TLR, and do
the following in InnocuousForkJoinWorkerThread:
185 static final class InnocuousForkJoinWorkerThread extends
On 01/11/2017 06:39 PM, Martin Buchholz wrote:
Doug, please try to remember the details of the thread group code.
>
> The threadgroup creation code that uses cheating has always seemed fishy
to me. The straightforward
>
> /**
> * Returns a new group with the sys
Doug, please try to remember the details of the thread group code.
On Wed, Jan 11, 2017 at 3:13 PM, Paul Sandoz wrote:
>
> > On 11 Jan 2017, at 14:00, Martin Buchholz wrote:
>
> > Our inline assignment style is non-standard, but we like it and it saves
> a byte of bytecode occasionally, making
> On 11 Jan 2017, at 14:00, Martin Buchholz wrote:
>
> Thanks, Paul.
>
> Looks good. Nits:
>
> ---
>
> Our inline assignment style is non-standard, but we like it and it saves a
> byte of bytecode occasionally, making things a tiny bit easier for the JIT.
>
Are you referring to cases like
On 1/11/17 5:43 AM, Claes Redestad wrote:
List2.hashCode()
ListN.hashCode()
MapN.hashCode()
aren't overridden.
I'd like to see them added at some point, but if your benchmarks don't justify
them, maybe they're not necessary right now. If not, we should make a note to
add them later.
As they
I haven't followed this much, but an observation: in Guava, we avoided
creating lots of specialized implementations for small collections, because
the JVM, at least at the time, had a sweet spot for bimorphic dispatch:
method calls where the real implementation would be one of two options, and
that
Thanks, Paul.
Looks good. Nits:
---
Our inline assignment style is non-standard, but we like it and it saves a
byte of bytecode occasionally, making things a tiny bit easier for the JIT.
---
The threadgroup creation code that uses cheating has always seemed fishy to
me. The straightforward
Thanks Roger!
-Joe
On 1/11/2017 10:38 AM, Roger Riggs wrote:
Hi Joe,
Thanks for the clarifications.
Looks good
Roger
On 1/10/2017 1:58 PM, huizhe wang wrote:
On 1/9/2017 2:17 PM, Roger Riggs wrote:
Hi Joe,
a few comments:
CatalogManager:
- line 58: "will /return /as no mapping is fo
Hi,
Please review:
http://cr.openjdk.java.net/~psandoz/jdk9/8160710-thread-to-tlr/webrev/
This patch updates ThreadLocalRandom, Striped64 and LockSupport to use
VarHandles instead of Unsafe to access fields in Thread, via the
MethodsHandles.privateLookupIn method.
Since there are three usag
Hi Joe,
Thanks for the clarifications.
Looks good
Roger
On 1/10/2017 1:58 PM, huizhe wang wrote:
On 1/9/2017 2:17 PM, Roger Riggs wrote:
Hi Joe,
a few comments:
CatalogManager:
- line 58: "will /return /as no mapping is found";
Or is it describing the behavior of the CatalogResolver
On Wed, Jan 11, 2017 at 5:43 AM, Claes Redestad
wrote:
>
>> ---
>>
>> In Set2, SetN, Map1, and MapN, the addition of @Stable also dropped the
>> "private" access modifier. Other implementations still have corresponding
>> fields as private. Was this intentional? I think they should all remain
In a library, when you receive externally an object at construction of
one of your class and mandate it to be immutable, you need to make a
defensive copy. Given new immutable collections, it would be useful to
have a factory for defensive copy, doing nothing if object to be copied
is already a
The change looks good.
Best
Lance
> On Jan 11, 2017, at 8:56 AM, David Buck wrote:
>
> approved for push to 8u-dev (contingent on successful code review)
>
> I have added the core libraries alias for what will hopefully be a trivial
> code review process.
>
> Cheers,
> -Buck
>
>
>
> On 2
> On 11 Jan 2017, at 07:03, Chris Hegarty wrote:
>
>
> On 01/11/2017 02:55 AM, Paul Sandoz wrote:
>> I am concerned it’s getting too late to twiddle with the security setting so
>> i took the plunge and wrapped the privateLookupIn calls in doPrivileged
>> blocks. It’s ugly but avoids the circ
Hi Peter,
You beat me to it!
My plan was to define a private method, accepting the lookup and teleporting
class, and encapsulating the doPrivileged block. Then i could call that method
for all usages in TLR. It does mean three doPrivileged executions, but that is
probably ok.
Thanks,
Paul.
>
Hi Attila,
On 01/11/2017 05:01 PM, Attila Szegedi wrote:
Collections.java:
4987 @Override
4988 public int hashCode() {
4989 return (k == null ? 0 : k.hashCode()) ^
4990(v == null ? 0 : v.hashCode());
Why not use Objects.hashCode here too, that is
Collections.java:
4987 @Override
4988 public int hashCode() {
4989 return (k == null ? 0 : k.hashCode()) ^
4990(v == null ? 0 : v.hashCode());
Why not use Objects.hashCode here too, that is return Objects.hashCode(k) ^
Objects.hashCode(v) ?
Attila
Backported changes look fine.
Regards,
Sean.
On 11/01/17 13:56, David Buck wrote:
approved for push to 8u-dev (contingent on successful code review)
I have added the core libraries alias for what will hopefully be a
trivial code review process.
Cheers,
-Buck
On 2017/01/11 22:01, Aleks Ef
On 01/11/2017 02:55 AM, Paul Sandoz wrote:
> I am concerned it’s getting too late to twiddle with the security setting so
> i took the plunge and wrapped the privateLookupIn calls in doPrivileged
> blocks. It’s ugly but avoids the circularity (JPRT core/hotspot testing has
> not failed).
>
> h
approved for push to 8u-dev (contingent on successful code review)
I have added the core libraries alias for what will hopefully be a
trivial code review process.
Cheers,
-Buck
On 2017/01/11 22:01, Aleks Efimov wrote:
Hello,
Please, approve a backport of JDK-8159058 to JDK8u-dev. This is
Hi Stuart,
On 01/11/2017 04:10 AM, Stuart Marks wrote:
On 1/10/17 3:50 AM, Claes Redestad wrote:
please review this change to improve startup/warmup characteristics
and performance of the immutable collection factories:
Bug: https://bugs.openjdk.java.net/browse/JDK-8166365
Webrev: http://cr.op
Hi Paul,
On 01/11/2017 02:55 AM, Paul Sandoz wrote:
I am concerned it’s getting too late to twiddle with the security setting so i
took the plunge and wrapped the privateLookupIn calls in doPrivileged blocks.
It’s ugly but avoids the circularity (JPRT core/hotspot testing has not failed).
htt
31 matches
Mail list logo
