Hi Martin,
I put the diffs in the public comments of 4863813, but if you can't wait
for bug.sun.com to catch up the diffs are attached.
-Chris.
On 27/08/2009 18:24, Martin Buchholz wrote:
Very interesting - thanks for the pointer to the bug id.
Chris, could you update the bug report to conta
I understand the advantage and as you wrote there are cases where this
is a disadvantage.
The thing is one can't even extend this class according the needed
functionality, since header is defined as private.
Guy
On Thu, Aug 27, 2009 at 8:27 PM, Martin Buchholz wrote:
> On Thu, Aug 27, 2009 at 10:
On Thu, Aug 27, 2009 at 10:23, Guy Korland wrote:
> First I don't think this is the same issue, in the clear case, there's
> no reference from the root to any of the entries.
> Second as I know any MarkAndSweep GC should not suffer from such issue.
> Since the sweep phase should collect any unreach
Very interesting - thanks for the pointer to the bug id.
Chris, could you update the bug report to contain a (public) diff
of the actual changes that were made?
The bug report does not mention clear().
Curiously, the jsr166 team has been working on fixing the same
kinds of issues in java.util.conc
First I don't think this is the same issue, in the clear case, there's
no reference from the root to any of the entries.
Second as I know any MarkAndSweep GC should not suffer from such issue.
Since the sweep phase should collect any unreachable entry no matter
how many dead references point to it.
I think this change was made to address:
4863813: Stressing single LinkedList from multiple threads causes
heapspace to completely
http://bugs.sun.com/view_bug.do?bug_id=4863813
-Chris.
Guy Korland wrote:
How does it help the GC?
As I understand the M&S algorithm, there's no real advantag
How does it help the GC?
As I understand the M&S algorithm, there's no real advantages in doing so.
In fact in many places to "null" references is considered to be an
anti pattern in java.
Guy
On Thu, Aug 27, 2009 at 4:37 PM, Tom Hawtin wrote:
> Guy Korland wrote:
>
>> It seems like linkedList.c
Guy Korland wrote:
It seems like linkedList.clear() can be easily fixed to O(1) instead of O(n).
The code is like that on purpose(!). It was done to help GC, in mustang
IIRC. There really isn't a problem with clear() being O(n) - it's going
to take at least O(n) to populate it, and in realit
First, LinkedList by definition is not thread safe so there's no need
to care about concurrency.
Second this is what modCount is all about, preventing an iterator to
keep on working.
Guy
On Thu, Aug 27, 2009 at 3:35 PM, Carsten Otto
wrote:
>
> On Thu, Aug 27, 2009 at 03:31:13PM +0300, Guy Korland
On Thu, Aug 27, 2009 at 03:31:13PM +0300, Guy Korland wrote:
> It seems like linkedList.clear() can be easily fixed to O(1) instead of O(n).
With your solution one would be possible to continue working (traversing)
on an empty (read: emptied) list. I don't think this is desired.
Best regards,
--
10 matches
Mail list logo
