- Original Message -
> From: "Staffan Larsen"
> To: "mark reinhold"
> Cc: core-libs-dev@openjdk.java.net
> Sent: Thursday, November 8, 2012 3:44:48 AM
> Subject: Re: Preliminary review: Adding tracing of I/O calls
>
>
> On 7 nov 20
On 7 nov 2012, at 23:22, mark.reinh...@oracle.com wrote:
> 2012/11/2 11:36 -0700, staffan.lar...@oracle.com:
>> Webrev: http://cr.openjdk.java.net/~sla/iotrace/webrev.00/
>
> Who (or what) is the intended consumer of the sun.misc.IoTrace and
> IoTraceListener APIs? In other words, are these mea
2012/11/2 11:36 -0700, staffan.lar...@oracle.com:
> Webrev: http://cr.openjdk.java.net/~sla/iotrace/webrev.00/
Who (or what) is the intended consumer of the sun.misc.IoTrace and
IoTraceListener APIs? In other words, are these meant to be stable
external interfaces that we're going to support for
On 11/07/2012 09:02 AM, Vitaly Davidovich wrote:
> I'd try the two different impls approach though. It does introduce more
> types to load but if that's not an issue, I think perf should be good. At
> least worth trying for curiosity's sake. :)
I wonder if this intersects with the dynamic tracin
On 07/11/2012 12:55, Staffan Larsen wrote:
:
Negative values means that my changes added a regression. I think most of these
values are within the margin of error in the measurements. The one exception is
FileChannelRead. I've rerun this many times and it looks fairly consistent
around a 4% r
On 11/07/2012 07:55 AM, Staffan Larsen wrote:
> An update on performance. I have written microbenchmarks for file and
> socket i/o and compared the results before my suggested changes and
> after.
>
> FileChannelRead -4.06% FileChannelWrite -1.06%
> FileInputStream0.92% FileOut
OK, just after I sent the email I realized public/private won't really give
JIT more confidence.
I'd try the two different impls approach though. It does introduce more
types to load but if that's not an issue, I think perf should be good. At
least worth trying for curiosity's sake. :)
Sent fro
On 7 nov 2012, at 14:53, Vitaly Davidovich wrote:
> Staffan,
>
> When you say you removed all implementation from fileBeginRead, do you mean
> you just return null instead of doing the ENABLED check?
>
Yes.
> Does making ENABLED private yield zero-cost? May give JIT more confidence
> that th
Staffan,
When you say you removed all implementation from fileBeginRead, do you mean
you just return null instead of doing the ENABLED check? Does making
ENABLED private yield zero-cost? May give JIT more confidence that this
field isn't modified via reflection from outside.
The other option is t
An update on performance. I have written microbenchmarks for file and socket
i/o and compared the results before my suggested changes and after.
FileChannelRead -4.06%
FileChannelWrite -1.06%
FileInputStream0.92%
FileOutputStream 1.32%
RandomAccessFileRead 1.66%
RandomA
On 4 nov 2012, at 16:13, Alan Bateman wrote:
> On 04/11/2012 12:50, Staffan Larsen wrote:
>> :
>>> I realize the focus is blocking I/O for now but one thing to know is that
>>> timed read operations on socket adapters (the socket obtained by calling
>>> SocketChannel's socket method) configure
No, I haven't considered dynamic instrumentation. It would be a lot more work
to implement it, and only worth it, I think, if the performance of the static
instrumentation is bad. One could do a little of both: leave the static
instrumentation in place, but change the IoTrace class to have only
Staffan,
Has dynamic instrumentation being considered for this project? I realize
it would require knowledge of the sites to instrument and I realize that
ignoring non-blocking I/O complicates it a bit too, I'm just wondering
if you've done any experiments to see if this would be an alternativ
On 04/11/2012 12:25, Aleksey Shipilev wrote:
.
class IoTrace {
public static final boolean ENABLED =
System.getProperty("java.io.trace");
}
...which will demote the flexibility of setListener(), but have much
lower runtime overhead. This should be confirmed by microbenchmarking
On 04/11/2012 12:50, Staffan Larsen wrote:
:
I realize the focus is blocking I/O for now but one thing to know is that timed
read operations on socket adapters (the socket obtained by calling
SocketChannel's socket method) configures the socket channel to be non-blocking
so this means that th
Thanks Alan. Some comments inline.
On 2 nov 2012, at 23:21, Alan Bateman wrote:
> On 02/11/2012 18:36, Staffan Larsen wrote:
>> This is a preliminary review request for adding an API for tracing I/O
>> calls. For now, this is an empty infrastructure intended to enable
>> diagnosing/tracing of
Aleksey,
Thanks for looking at the code. I have been running volano on this, but could
not detect any regressions. If that is because there are no regressions,
because volano is not the right workload or because the run-to-run variance is
so high, I cannot say.
I'm going to try to develop micr
On 11/03/2012 01:15 AM, Mandy Chung wrote:
> On 11/2/2012 1:47 PM, Staffan Larsen wrote:
>> On 2 nov 2012, at 21:12, Mandy Chung wrote:
>>
>>> The *Begin() methods return a "handle" that will be passed to the
>>> *End() methods. Have you considered to define a type for it rather
>>> than Object?
On 02/11/2012 18:36, Staffan Larsen wrote:
This is a preliminary review request for adding an API for tracing I/O calls.
For now, this is an empty infrastructure intended to enable diagnosing/tracing
of i/o calls. A user of the API can register a listener and get callbacks for
read and write o
On 11/2/2012 1:47 PM, Staffan Larsen wrote:
On 2 nov 2012, at 21:12, Mandy Chung wrote:
The *Begin() methods return a "handle" that will be passed to the *End()
methods. Have you considered to define a type for it rather than Object?
Something like an empty interface, just to signal the int
On 11/02/2012 09:49 PM, Staffan Larsen wrote:
Thanks, Jim. I'll come back with micro-benchmark numbers.
/Staffan
I think this code is a good candidate for the almost final design pattern :)
http://weblogs.java.net/blog/forax/archive/2011/12/17/jsr-292-goodness-almost-static-final-field
Basica
Thanks, Jim. I'll come back with micro-benchmark numbers.
/Staffan
On 2 nov 2012, at 21:27, Jim Gish wrote:
> Hi Staffan,
>
> This looks fine to me as well, but I had the same question as Mandy about
> performance. Given the sensitivity to changes in I/O it would be good to
> have some micr
On 2 nov 2012, at 21:12, Mandy Chung wrote:
> Hi Staffan,
>
> On 11/2/2012 11:36 AM, Staffan Larsen wrote:
>> This is a preliminary review request for adding an API for tracing I/O
>> calls. For now, this is an empty infrastructure intended to enable
>> diagnosing/tracing of i/o calls. A user
Hi Staffan,
This looks fine to me as well, but I had the same question as Mandy
about performance. Given the sensitivity to changes in I/O it would be
good to have some micro-benchmarks here.
Thanks,
Jim
On 11/02/2012 04:12 PM, Mandy Chung wrote:
Hi Staffan,
On 11/2/2012 11:36 AM, Staff
Hi Staffan,
On 11/2/2012 11:36 AM, Staffan Larsen wrote:
This is a preliminary review request for adding an API for tracing I/O calls.
For now, this is an empty infrastructure intended to enable diagnosing/tracing
of i/o calls. A user of the API can register a listener and get callbacks for
r
This is a preliminary review request for adding an API for tracing I/O calls.
For now, this is an empty infrastructure intended to enable diagnosing/tracing
of i/o calls. A user of the API can register a listener and get callbacks for
read and write operations on sockets and files. It does not (
26 matches
Mail list logo
