You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Rodrigo Kumpera <ku...@gmail.com> on 2006/01/23 18:12:09 UTC
java.util.concurrent implementation
Can we import the backport of jsr-166 as the starting point for
implementing this package? It's released as public domain, so there
should be not license issue IFAIK.
There are only a few things required make it work, like removing
references to com.sun.Unsafe.
Re: java.util.concurrent implementation
Posted by Tim Ellison <t....@gmail.com>.
OK -- thanks Rodrigo.
Those types of atomic ops are not in the OSMemory type right now. If we
get the concurrent code we can look at the full set of requirements and
implement them in classlib.
Regards,
Tim
Rodrigo Kumpera wrote:
> util.concurrent needs two pieces of "unsafe" functionality: atomic
> operations like compare and set, compare and increment, etc; and field
> offset discovering needed by AtomicIntegerFieldUpdater, for example.
> The other parts don't require special handling besides LockSupport
> with would benefit from som changes in java.lang.Thread.
>
>
>
> On 1/24/06, Tim Ellison <t....@gmail.com> wrote:
>> AIUI the Unsafe type is Sun's means of manipulating OS heap memory --
>> classlib has a type that does that (currently in NIO module, and called
>> com.ibm.platform.OSMemory, though I agree with Paulex that it should
>> move into LUNI). If the functionality of OSMemory is lacking we can, of
>> course, extend it to support concurrent.
>>
>> Regards,
>> Tim
>>
>> Rodrigo Kumpera wrote:
>>> Can we import the backport of jsr-166 as the starting point for
>>> implementing this package? It's released as public domain, so there
>>> should be not license issue IFAIK.
>>>
>>> There are only a few things required make it work, like removing
>>> references to com.sun.Unsafe.
>>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: java.util.concurrent implementation
Posted by Rodrigo Kumpera <ku...@gmail.com>.
util.concurrent needs two pieces of "unsafe" functionality: atomic
operations like compare and set, compare and increment, etc; and field
offset discovering needed by AtomicIntegerFieldUpdater, for example.
The other parts don't require special handling besides LockSupport
with would benefit from som changes in java.lang.Thread.
On 1/24/06, Tim Ellison <t....@gmail.com> wrote:
> AIUI the Unsafe type is Sun's means of manipulating OS heap memory --
> classlib has a type that does that (currently in NIO module, and called
> com.ibm.platform.OSMemory, though I agree with Paulex that it should
> move into LUNI). If the functionality of OSMemory is lacking we can, of
> course, extend it to support concurrent.
>
> Regards,
> Tim
>
> Rodrigo Kumpera wrote:
> > Can we import the backport of jsr-166 as the starting point for
> > implementing this package? It's released as public domain, so there
> > should be not license issue IFAIK.
> >
> > There are only a few things required make it work, like removing
> > references to com.sun.Unsafe.
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: java.util.concurrent implementation
Posted by Tim Ellison <t....@gmail.com>.
AIUI the Unsafe type is Sun's means of manipulating OS heap memory --
classlib has a type that does that (currently in NIO module, and called
com.ibm.platform.OSMemory, though I agree with Paulex that it should
move into LUNI). If the functionality of OSMemory is lacking we can, of
course, extend it to support concurrent.
Regards,
Tim
Rodrigo Kumpera wrote:
> Can we import the backport of jsr-166 as the starting point for
> implementing this package? It's released as public domain, so there
> should be not license issue IFAIK.
>
> There are only a few things required make it work, like removing
> references to com.sun.Unsafe.
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: java.util.concurrent implementation
Posted by Rodrigo Kumpera <ku...@gmail.com>.
Some of the concurrent collections have code from the JDK, but these
can be just discarded. The pedigree can be asserted by Doug Lea
himself, I think he is on the list.
It was the intent of the expert group to allow the reference
implementation be used by FOSS jvms.
Rodrigo,
On 1/23/06, Davanum Srinivas <da...@gmail.com> wrote:
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/readme?annotate=1.1
>
> On 1/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> > The question I'd have is who wrote it - is there any exposure risk?
> > "public domain" doesn't mean "clean pedigree"...
> >
> > But yes, certainly worth investigating. Can you look into it?
> >
> > Rodrigo Kumpera wrote:
> > > Can we import the backport of jsr-166 as the starting point for
> > > implementing this package? It's released as public domain, so there
> > > should be not license issue IFAIK.
> > >
> > > There are only a few things required make it work, like removing
> > > references to com.sun.Unsafe.
> > >
> > >
> >
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
Re: java.util.concurrent implementation
Posted by Davanum Srinivas <da...@gmail.com>.
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/readme?annotate=1.1
On 1/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> The question I'd have is who wrote it - is there any exposure risk?
> "public domain" doesn't mean "clean pedigree"...
>
> But yes, certainly worth investigating. Can you look into it?
>
> Rodrigo Kumpera wrote:
> > Can we import the backport of jsr-166 as the starting point for
> > implementing this package? It's released as public domain, so there
> > should be not license issue IFAIK.
> >
> > There are only a few things required make it work, like removing
> > references to com.sun.Unsafe.
> >
> >
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: java.util.concurrent implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
The question I'd have is who wrote it - is there any exposure risk?
"public domain" doesn't mean "clean pedigree"...
But yes, certainly worth investigating. Can you look into it?
Rodrigo Kumpera wrote:
> Can we import the backport of jsr-166 as the starting point for
> implementing this package? It's released as public domain, so there
> should be not license issue IFAIK.
>
> There are only a few things required make it work, like removing
> references to com.sun.Unsafe.
>
>