Switch to atomic ops for the various sequence numbers, as opposed to
synchronizing on the class object on every object construction.
- DML
--
diff -r dde3fe2e8164 src/share/classes/java/util/logging/LogRecord.java
--- a/src/share/classes/java/util/logging/LogRecord.java Wed Feb 25
14:32:01 200
You might want to have a look at the new contribution process [1].
Using that will increase the probability that someone will evaluate
your patch sooner rather than later.
- Mark
[1] http://openjdk.java.net/contribute
On 03/12/2009 05:41 PM, Mark Reinhold wrote:
You might want to have a look at the new contribution process [1].
Using that will increase the probability that someone will evaluate
your patch sooner rather than later.
- Mark
[1] http://openjdk.java.net/contribute
Consider my post to be step 2
This looks fine, as long as there is no dependency of the implementation
on the two atomic counters being incremented in concert, as seems likely.
Martin
On Thu, Mar 12, 2009 at 15:35, David M. Lloyd wrote:
> Switch to atomic ops for the various sequence numbers, as opposed to
> synchronizing on
David M. Lloyd wrote:
> On 03/12/2009 05:41 PM, Mark Reinhold wrote:
>> You might want to have a look at the new contribution process [1].
>> Using that will increase the probability that someone will evaluate
>> your patch sooner rather than later.
>>
>> - Mark
>>
>> [1] http://openjdk.java.net/co
2009/3/13 Dalibor Topic :
> David M. Lloyd wrote:
>> On 03/12/2009 05:41 PM, Mark Reinhold wrote:
>>> You might want to have a look at the new contribution process [1].
>>> Using that will increase the probability that someone will evaluate
>>> your patch sooner rather than later.
>>>
>>> - Mark
>>
On 03/12/2009 07:01 PM, Dalibor Topic wrote:
David M. Lloyd wrote:
On 03/12/2009 05:41 PM, Mark Reinhold wrote:
You might want to have a look at the new contribution process [1].
Using that will increase the probability that someone will evaluate
your patch sooner rather than later.
- Mark
[1
I couldn't think of any situation where there would be.
- DML
On 03/12/2009 06:46 PM, Martin Buchholz wrote:
This looks fine, as long as there is no dependency of the implementation
on the two atomic counters being incremented in concert, as seems likely.
Martin
On Thu, Mar 12, 2009 at 15:35,
2009/3/12 Martin Buchholz :
> This looks fine, as long as there is no dependency of the implementation
> on the two atomic counters being incremented in concert, as seems likely.
>
> Martin
>
> On Thu, Mar 12, 2009 at 15:35, David M. Lloyd wrote:
>> Switch to atomic ops for the various sequence nu
2009/3/13 David M. Lloyd :
> On 03/12/2009 07:01 PM, Dalibor Topic wrote:
>>
>> David M. Lloyd wrote:
>>>
>>> On 03/12/2009 05:41 PM, Mark Reinhold wrote:
You might want to have a look at the new contribution process [1].
Using that will increase the probability that someone will eva
On 03/12/2009 07:13 PM, Andrew John Hughes wrote:
This is actually an interesting rare case where two atomic variables
can replace a synchronised block. Looking at the code, there seems to
be no issue with the thread being descheduled and then resumed during
the operation of this constructor. B
2009/3/13 David M. Lloyd :
> On 03/12/2009 07:13 PM, Andrew John Hughes wrote:
>>
>> This is actually an interesting rare case where two atomic variables
>> can replace a synchronised block. Looking at the code, there seems to
>> be no issue with the thread being descheduled and then resumed durin
Opened as a BugZilla bug:
https://bugs.openjdk.java.net/show_bug.cgi?id=100021
- DML
On 03/12/2009 05:35 PM, David M. Lloyd wrote:
Switch to atomic ops for the various sequence numbers, as opposed to
synchronizing on the class object on every object construction.
David M. Lloyd wrote:
>
>> It seems that the change would break serialization, by changing the type
>> of a serialized field (in both classes) away from a primitive one. See
>> http://java.sun.com/javase/6/docs/platform/serialization/spec/version.html
>>
>> for details.
>
> The fields are static
2009/3/13 Dalibor Topic :
> David M. Lloyd wrote:
>>
>>> It seems that the change would break serialization, by changing the type
>>> of a serialized field (in both classes) away from a primitive one. See
>>> http://java.sun.com/javase/6/docs/platform/serialization/spec/version.html
>>>
>>> for det
On Thu, Mar 12, 2009 at 17:21, Andrew John Hughes
wrote:
> I agree. I also noticed that Thread uses a synchronised block to do
> the increment rather than the atomic. I don't know if there'd be any
> advantage to changing it or whether there is a good reason it was done
> like that.
java.lang.T
Martin,
I was thinking we could special case the first thread and have it do the
initialization when "safe". (The first thread is the only case where it
appears to be its own parent, or in other words, where
Thread.currentThread()==this.
But let's not hijack this thread for this discussion.
Andrew John Hughes said the following on 03/13/09 10:13:
The rest of the code deals with allocating an ID to the
thread creating the LogRequest object and doesn't depend on the global
sequence number, so it doesn't matter if this is incremented by
another thread before the constructor completes.
18 matches
Mail list logo
