Hi,
Signature hashCode (the static class in MethodUtil) should be eagerly
calculated (i.e. a final field too) since the only usage is being a key in
the hashmap.
I will add bit more later.
Stanimir
On Wed, Nov 19, 2014 at 2:42 AM, Martin Buchholz
wrote:
> Hi Joe, Peter, Paul
>
> This is the f
On 19/11/2014 2:02 AM, Martin Buchholz wrote:
On Mon, Nov 17, 2014 at 9:02 PM, David Holmes wrote:
Hi Martin,
On 18/11/2014 2:49 PM, Martin Buchholz wrote:
Hi David,
I'm still hoping to persuade you (and others) to fix the long-standing
return-early bug in Object.wait.
Are you referring
Hi Roger,
On 19/11/2014 8:28 AM, roger riggs wrote:
Hi,
Done, added the test and immediate return after the wait.
On Windows, the Thread.interrupted check needs to be done first to be
consistent with Unix.
Refactored a bit to remove a local variable and extra arithmetic
computing the remaining
Hi Joe, Peter, Paul
This is the followup on thread safety I promised Peter.
As I said before, I'm willing to take the risk to use fields written
via a race if we have a reflective test proving it correct, and the
bug contains the 0.1 version of such a test.
https://bugs.openjdk.java.net/browse/JD
On 11/18/2014 11:23 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8063135/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8063135
Broken array index here:
69 TRACE_METHOD_LINKAGE = (Boolean) values[3];
70 COMPILE_THRESHOLD = (Integer) value
On 11/19/2014 12:01 AM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8059880/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8059880
Yes, for the love of God, GO FOR IT.
-Aleksey.
Hi,
Done, added the test and immediate return after the wait.
On Windows, the Thread.interrupted check needs to be done first to be
consistent with Unix.
Refactored a bit to remove a local variable and extra arithmetic
computing the remainingNanos.
Updated:
http://cr.openjdk.java.net/~rriggs
http://cr.openjdk.java.net/~vlivanov/8059880/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8059880
Once full LambdaForm sharing is on by default, amount of instantiated
LambdaForms drastically reduces. On Octane it varies from 1k to 3k
depending on the subbenchmark (was up to 300k before
I think we're all 3 in agreement on the general direction, even if we
disagree on the details.
Once we properly round to millis, it is no longer necessary to use
Math.max - just
wait(NANOSECONDS.toMillis(rem + 999_999L));
As in my proposed change, I would like every call to wait immediately
foll
http://cr.openjdk.java.net/~vlivanov/8063135/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8063135
Turn on full LambdaForm sharing and get rid of custom LambdaForm shapes.
8059877 [1] eliminated most of the regressions caused by LF sharing. The
rest will be addressed separately [2].
Tes
Hi,
Work on Object.wait is an issue to be taken up separately.
I agree that the timeout values should not be truncated to milliseconds,
likely
causing an additional cycle through the while loop and waiting.
The Process.waitFor methods are expected to wait for the specified time
to elapse.
The
Hi Bernd,
If you can swap the default ThreadLocal with your own implementation (a
subclass of ThreadLocal), you can make it behave like you would like it
to (It's a hack, I know ;-)
public class XThreadLocal extends ThreadLocal {
private static class Null extends RuntimeException {
Hi Frank,
The webrev is updated and looks good now.
Thanks for the great work!
Joe
On 11/13/2014 3:02 AM, Frank Yuan wrote:
Hi Joe and All
I revised the code based on latest comments and put the webrev on
http://cr.openjdk.java.net/~joehw/jdk9/test/Frank/8043090/webrev/
Best Regards
Frank
On Mon, Nov 17, 2014 at 8:54 PM, David Holmes wrote:
> On 18/11/2014 2:43 PM, Martin Buchholz wrote:
>>
>> Proposed sibling change
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/UNIXProcess.waitFor/
>> - don't unconditionally call nanoTime when the wait ends
>> - use the millis/nanos form
Am Tue, 18 Nov 2014 15:36:09 +
schrieb Chris Hegarty :
> > Yes, either the contract has to change, or the empty
> > default implementation of initial value is changed to not return
> > null but INITIAL.
>
> Yes, that was my initial thought too, but unfortunately initialValue
> specifies that
On Mon, Nov 17, 2014 at 9:02 PM, David Holmes wrote:
> Hi Martin,
>
> On 18/11/2014 2:49 PM, Martin Buchholz wrote:
>>
>> Hi David,
>>
>> I'm still hoping to persuade you (and others) to fix the long-standing
>> return-early bug in Object.wait.
>
>
> Are you referring to the low level mechanics or
On 18/11/14 15:14, Bernd Eckenfels wrote:
Am Tue, 18 Nov 2014 15:12:46 +
schrieb Chris Hegarty :
Interesting idea. If this was to be the case woultn't multiple get()
invocations cause multiple initialValue() invocations?
I think storing the null is important to obey the initialValue /
remo
Am Tue, 18 Nov 2014 15:12:46 +
schrieb Chris Hegarty :
> Interesting idea. If this was to be the case woultn't multiple get()
> invocations cause multiple initialValue() invocations?
>
> I think storing the null is important to obey the initialValue /
> remove contract, i.e. initialValue met
On 18/11/14 05:11, Bernd Eckenfels wrote:
What do you think? (code from OpenJDK 8:)
179private T setInitialValue() {
180T value = initialValue();
181Thread t = Thread.currentThread();
182ThreadLocalMap map = getMap(t);
183if (map != null)
184m
Hello,
after eating something I understood what you mean :) Yes you are right,
with the proposed change the initialValue would be called much more
often if it returns (after longish compilation or in the trivial case)
null.
Not sure if this is a loss compared to not constructing the entry.
Just
Am Tue, 18 Nov 2014 11:37:34 +
schrieb Tom Hawtin :
> On 18/11/2014 05:11, Bernd Eckenfels wrote:
>
> > Unfortunatelly the ThreadLocal#get() will call #setInitialValue() in
> > all cases, and this will in turn call createMap(). setInitialValue()
> > could avoid to call createMap() when value
For those of you not aware, an IETF group is currently defining a time
zone distribution service "tzdist":
http://tools.ietf.org/html/draft-ietf-tzdist-service-03
It will be worth considering whether this might be of use to Java to
provide a mechanism to update time zone data. Readers of this list
On 18/11/2014 05:11, Bernd Eckenfels wrote:
Unfortunatelly the ThreadLocal#get() will call #setInitialValue() in
all cases, and this will in turn call createMap(). setInitialValue()
could avoid to call createMap() when value is null. This would reduce
the number of created thread specific maps a
On 17/11/14 23:27, Pavel Rappo wrote:
Hi everyone,
I've been working with the URLConnection class for some time now and have
noticed several interesting things.
1. Unsafe publication of java.net.URLConnection.factory static field (it looks
very similar to [1])
2. Benign race condition in ja
24 matches
Mail list logo
