On 01/11/2011 09:47, Seán Coffey wrote:
:
Are you referring to the parent.close() call ? If otherParents is
null, then we only have one reference to this FileDesriptor - i.e the
Stream that has called close().
It's parent.close() that I'm wondering about. Suppose p1 is the parent,
p2 is in ot
Hi, Mark.
You gave me a copy of those test when I was working on this bug:
4463011: (bf) View-buffer bulk get/put operations are slow
If I recall correctly, I modified the tests for my particular problem
and added them to that bug as attachments.
iris
-Original Message-
From: Mark Rein
2011/11/1 17:07 -0700, david.hol...@oracle.com:
> I'm looking into refactoring all the generated buffer classes to reduce the
> number of classes created. Part of that requires a performance comparison
> between the old and new classes. So I'm looking for any benchmarks that may
> exist to measure
On 11/01/2011 11:09 PM, Seán Coffey wrote:
The fd count was only used if it was the finalizer thread. Any
explicit close() call not from finalizer meant that the FD got closed.
/*
* If FileDescriptor is still in use by another stream, the
finalizer
* will not close i
Need to cast a wide net here to try and catch past and present NIO
developers/users.
I'm looking into refactoring all the generated buffer classes to reduce
the number of classes created. Part of that requires a performance
comparison between the old and new classes. So I'm looking for any
be
Hi Darryl,
On 2/11/2011 3:51 AM, Darryl Mocek wrote:
Hello. Please review this patch to fix Bug #6578042
(System.clearProperty() throws ClassCastException if property value
isn't a String). The issue is that through the Hashtable methods, it's
possible to add a Property which isn't a String and
Changeset: 9e2eb4bc49eb
Author:jjh
Date: 2011-11-01 15:49 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9e2eb4bc49eb
7101933: langtools jtreg tests do not work with jprt on windows
Summary: Fixed langtools/test/Makefile to work on cygwin. Updated jtreg to 4.1
and JCK
Hello. Please review this patch to fix Bug #6578042
(System.clearProperty() throws ClassCastException if property value
isn't a String). The issue is that through the Hashtable methods, it's
possible to add a Property which isn't a String and set it through
System.setProperties. clearPropert
On 11/01/2011 11:09 PM, Seán Coffey wrote:
If FileDescriptor is still
/*
* If FileDescriptor is still in use by another stream, the
finalizer
* will not close it.
*/
if ((useCount <= 0) || !isRunningFinalize()) {
close0();
}
Hi S
The fd count was only used if it was the finalizer thread. Any explicit
close() call not from finalizer meant that the FD got closed.
/*
* If FileDescriptor is still in use by another stream, the
finalizer
* will not close it.
*/
if ((useCount <= 0) |
On 11/01/2011 10:46 PM, Seán Coffey wrote:
Charles,
Yes - all three streams will now be closed. Previous to 7082769, when
any of the streams calls close(), the underlying filedescriptor used
get closed out via the native close0() call.
A list of Closeables is maintained by FileDescriptor.
r
Charles,
Yes - all three streams will now be closed. Previous to 7082769, when
any of the streams calls close(), the underlying filedescriptor used get
closed out via the native close0() call.
A list of Closeables is maintained by FileDescriptor.
regards,
Sean.
On 01/11/2011 13:54, Charles
On 10/29/2011 02:13 AM, Seán Coffey wrote:
This is a second stab at cleaning up the close() and finalize()
methods for FileInputStream / FileOutputStream / RandomAccessFile
classes so that all parents/referents sharing the same native
FileDescriptor are closed out correctly.
With Alan's assi
On 30/10/2011 16:33, Alan Bateman wrote:
On 28/10/2011 19:13, Seán Coffey wrote:
This is a second stab at cleaning up the close() and finalize()
methods for FileInputStream / FileOutputStream / RandomAccessFile
classes so that all parents/referents sharing the same native
FileDescriptor are
14 matches
Mail list logo
