On 01/25/2016 05:14 PM, Alan Bateman wrote:
On 25/01/2016 15:27, Peter Levart wrote:
But let me ask something. Doesn't GC processing require (at least in
some phases) that user threads be stopped in a safepoint? What
happens when a user thread is blocked by kernel on memory access?
Such
Hi,
On 01/25/2016 08:32 PM, Gil Tene wrote:
I assume your goal here is to get the resources released with the next newgen
collections (following a close()), rather than wait for an oldgen (if the
resource was held by an old object). That's a cool thing.
With that in mind, you can replace the
: Tuesday, January 26, 2016 5:49 PM
>> To: 'Chris Hegarty' ; 'Alan Bateman'
>> ; 'Roger Riggs' ;
>> uschind...@apache.org
>> Cc: 'core-libs-dev'
>> Subject: RE: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref
>>
>
> -
> Uwe Schindler
> uschind...@apache.org
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
> > -Original Message-
> > From: Chris Hegarty [mailto:chris.hega...@oracle.com]
> > Sent: Tuesday, January
> On Jan 26, 2016, at 8:27 AM, Chris Hegarty wrote:
>
> Latest webrev updated in-place:
> http://cr.openjdk.java.net/~chegar/8148117/
>
> * to execute the run method requires an appropriate permission
> * reverted any copyright changes ( leave to a bulk update )
> * updated the test to remove
On 26/01/2016 16:27, Chris Hegarty wrote:
Latest webrev updated in-place:
http://cr.openjdk.java.net/~chegar/8148117/
* to execute the run method requires an appropriate permission
* reverted any copyright changes ( leave to a bulk update )
* updated the test to remove the script
-Ch
Message-
> From: Chris Hegarty [mailto:chris.hega...@oracle.com]
> Sent: Tuesday, January 26, 2016 5:28 PM
> To: Alan Bateman ; Roger Riggs
> ; uschind...@apache.org
> Cc: core-libs-dev
> Subject: Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref
>
> Latest w
Latest webrev updated in-place:
http://cr.openjdk.java.net/~chegar/8148117/
* to execute the run method requires an appropriate permission
* reverted any copyright changes ( leave to a bulk update )
* updated the test to remove the script
-Chris.
On 26 Jan 2016, at 15:23, Alan Bateman wro
On 26 Jan 2016, at 16:36, Roger Riggs wrote:
> Hi Chris,
>
> Looks good, thanks for updating the test.
>
> One typo:
> "Unexpected exist
> code”
D’oh. Fixed in-place.
-Chris
> Roger
>
>
>
> On 1/26/2016 11:27 AM, Chris Hegarty wrote:
>> Latest webrev updated in-place:
>>
>> http://
Hi Chris,
Looks good, thanks for updating the test.
One typo:
"Unexpected *exist *code" Roger
On 1/26/2016 11:27 AM, Chris Hegarty wrote:
Latest webrev updated in-place:
http://cr.openjdk.java.net/~chegar/8148117/
* to execute the run method requires an appropriate permission
* rever
On 26/01/2016 13:55, Chris Hegarty wrote:
It is wonderful to see the various ideas on this thread about the longer
term solution to the prompt releasing of direct buffer native memory. I
do not want to obstruct that ( it is very informative ), but I’d like to warp up
the review on the actual movi
Hi Chris,
Looks fine.
Perhaps update the copyrights.
Upgrading the shell based test to java based would be good sometime too.
Also, there is a more recent version of webrev [1] that provides
convenient next and previous links.
Thanks, Roger
[1] http://hg.openjdk.java.net/code-tools/webrev/
Hi,
> On 26/01/2016 14:05, Uwe Schindler wrote:
> > Hi,
> >
> > looks good to me. Once we have EA builds with that I will adapt the
> ByteBufferIndexInput code in Lucene.
> >
> > One thing about the Runable: This should work perfectly fine, because we
> only need to make call the getCleaner() meth
On 26/01/2016 14:05, Uwe Schindler wrote:
Hi,
looks good to me. Once we have EA builds with that I will adapt the
ByteBufferIndexInput code in Lucene.
One thing about the Runable: This should work perfectly fine, because we only
need to make call the getCleaner() method accessible, call it
n Bateman ; core-libs-dev d...@openjdk.java.net>
> Subject: Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref
>
> It is wonderful to see the various ideas on this thread about the longer
> term solution to the prompt releasing of direct buffer native memory. I
>
> On 23 Jan 2016, at 21:31, Andrew Haley wrote:
>
> BTW, does anyone here know why we don't have humongous ByteBuffers
> with a long index?
>
Probably in part because of Java arrays. IMO we need Arrays 2.0 (+ panama i
suspect).
Here’s some "shoot from the hip" thinking…
In principle a direc
It is wonderful to see the various ideas on this thread about the longer
term solution to the prompt releasing of direct buffer native memory. I
do not want to obstruct that ( it is very informative ), but I’d like to warp
up
the review on the actual moving of Cleaner. To that end, I’ve update th
I assume your goal here is to get the resources released with the next newgen
collections (following a close()), rather than wait for an oldgen (if the
resource was held by an old object). That's a cool thing.
With that in mind, you can replace the repeated periodic
polling/flipping/allocation
On 25/01/2016 15:27, Peter Levart wrote:
But let me ask something. Doesn't GC processing require (at least in
some phases) that user threads be stopped in a safepoint? What happens
when a user thread is blocked by kernel on memory access? Such thread
can't be stopped in a safepoint. Safepoi
On 01/25/2016 02:31 PM, Alan Bateman wrote:
On 24/01/2016 17:10, Peter Levart wrote:
Hi,
I had an idea recently on how to expedite the collection of an
object. It is simple - just don't let it live long.
Here's a concept prototype:
http://cr.openjdk.java.net/~plevart/misc/CloseableMemory/
On 24/01/2016 17:10, Peter Levart wrote:
Hi,
I had an idea recently on how to expedite the collection of an object.
It is simple - just don't let it live long.
Here's a concept prototype:
http://cr.openjdk.java.net/~plevart/misc/CloseableMemory/CloseableMemory.java
The overhead of the ch
Hi,
I had an idea recently on how to expedite the collection of an object.
It is simple - just don't let it live long.
Here's a concept prototype:
http://cr.openjdk.java.net/~plevart/misc/CloseableMemory/CloseableMemory.java
The overhead of the check in access methods (getByte()/setByte())
-
> From: Chris Hegarty [mailto:chris.hega...@oracle.com]
> Sent: Saturday, January 23, 2016 11:52 PM
> To: Uwe Schindler
> Cc: Alan Bateman ; core-libs-dev d...@openjdk.java.net>
> Subject: Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref
>
> Just catching up…
>
Just catching up…
I see no objection to the proposed patch, but the obvious concern ( that
is highlighted in JEP 260 ), about the digging into the private internal
details of NIO buffers.
I think Alan summarized the issues around providing a public API for
releasing/unmapping native memory very
Hi Andrew,
Andrew Haley [mailto:a...@redhat.com] wrote:
> On 23/01/16 20:01, Uwe Schindler wrote:
>
> > It depends how small! If the speed is still somewhere between Java 8
> > ByteBuffer performance and the recent Hotspot improvements in Java
> > 9, I agree with trying it out. But some volatile
Hi,
Alan Bateman [mailto:alan.bate...@oracle.com] wrote:
> On 23/01/2016 19:23, Uwe Schindler wrote:
> > :
> >
> > What is the replacement for the following code (see marked BufferCleaner
> impl, which is our abstraction): https://goo.gl/DGYZZj
> >
> > The main reason why sun.misc.Cleaner was on t
On 23/01/2016 19:23, Uwe Schindler wrote:
:
What is the replacement for the following code (see marked BufferCleaner impl,
which is our abstraction): https://goo.gl/DGYZZj
The main reason why sun.misc.Cleaner was on the critical API list is NOT the
case that somebody wanted to implement thei
On 23/01/16 20:01, Uwe Schindler wrote:
> It depends how small! If the speed is still somewhere between Java 8
> ByteBuffer performance and the recent Hotspot improvements in Java
> 9, I agree with trying it out. But some volatile memory access on
> every access is a no-go. The code around ByteBuf
Hi,
> Here's a question for you: could you tolerate a closeable mapped
> ByteBuffer which was somewhat slower to access? It is hard to make a
> secure closeable mapped ByteBuffer: the question is how small the
> overhead of closeability can be made.
Lucene uses the ByteBuffer like a conventional
Here's a question for you: could you tolerate a closeable mapped
ByteBuffer which was somewhat slower to access? It is hard to make a
secure closeable mapped ByteBuffer: the question is how small the
overhead of closeability can be made.
But if the answer is "We can't tolerate *any* additional ov
(reposting with correct sender address)
Hi,
> Note: some popular open source libraries that hack into the internal
> private cleaner field of direct buffers will have to have their code
> updated, if they wish to continue to do this.
I followed parts of this issue, but as representative from Apa
On 23/01/2016 16:16, Chris Hegarty wrote:
:
Webrev:
http://cr.openjdk.java.net/~chegar/8148117/
This has to move to your patch looks okay. You might need to update the
TEST.groups to ensure that the existOnThrow tests will be run by jdk_core.
-Alan.
32 matches
Mail list logo
