Hey guys. Any idea where I can find instructions on how to use JMH to:
1. Clear OS' file reading cache.
2. Warm up whatever it needs to (maybe reading from a Channel in memory).
3. Create a BufferedInputStream with a FileInputStream inside, with
configurable buffer sizes.
4. Execute iterations
I believe I see where you coming from. Please correct me if I'm wrong.
Your implementation is based on the premise that a call to
ReadableByteChannel.read()
_initiates_ the operation and returns immediately. The OS then continues to fill
the buffer while there's a free space in the buffer and th
Hi,
does this commentary suffice?
http://cr.openjdk.java.net/~redestad/8168640/webrev.02/
To answer Paul's question about the exact startup gain:
20 named classes observable with -Xlog:class+load (11
additional anonymous show up in heap dumps), for example:
java.lang.invoke.MethodType$Concu
It is actually based on the premise that:
1. The first call to ReadableByteChannel.read(ByteBuffer) sets the OS
buffer size to fill in as the same size as ByteBuffer.
2. The consecutive calls to ReadableByteChannel.read(ByteBuffer) orders
the JVM to order the OS to execute memcpy() to copy
Hi,
Please find below a small patch for
8163162: The separation between system loggers and application
loggers should take the extension loader in consideration.
https://bugs.openjdk.java.net/browse/JDK-8163162
With the deprivileging of some JDK modules, classes loaded
by the Platform
Thanks, Fixed and pushed
On 10/25/2016 5:35 PM, Paul Sandoz wrote:
On 25 Oct 2016, at 14:28, Roger Riggs wrote:
Hi Paul,
Thanks for explanation and suggestions.
I updated the webrev to use instance methods and fields and using synchronized.
(And a bit of long-line cleanup.)
webrev:
htt
On 10/26/2016 02:11 PM, Claes Redestad wrote:
does this commentary suffice?
http://cr.openjdk.java.net/~redestad/8168640/webrev.02/
Yes, that's good. Thanks.
Regards, Peter
Hi Daniel,
It is common now to use a lambda for the target of doPriv; its a bit
lighter weight
as it becomes a method reference instead of an additional inner class.
Looks fine with or without the lambda.
Roger
On 10/26/2016 9:58 AM, Daniel Fuchs wrote:
Hi,
Please find below a small patch
On 26/10/2016 13:11, Claes Redestad wrote:
Hi,
does this commentary suffice?
http://cr.openjdk.java.net/~redestad/8168640/webrev.02/
To answer Paul's question about the exact startup gain:
20 named classes observable with -Xlog:class+load (11
additional anonymous show up in heap dumps), for
On 2016-10-26 17:10, Alan Bateman wrote:
On 26/10/2016 13:11, Claes Redestad wrote:
Hi,
does this commentary suffice?
http://cr.openjdk.java.net/~redestad/8168640/webrev.02/
To answer Paul's question about the exact startup gain:
20 named classes observable with -Xlog:class+load (11
additio
Hi Roger,
On 26/10/16 16:06, Roger Riggs wrote:
Hi Daniel,
It is common now to use a lambda for the target of doPriv; its a bit
lighter weight
as it becomes a method reference instead of an additional inner class.
Yes - I've been bitten before with using lambda
in logging code - especially in
Hi Brunoais,
I'll try to tell what I know from my JMH practice:
On 10/26/2016 10:30 AM, Brunoais wrote:
Hey guys. Any idea where I can find instructions on how to use JMH to:
1. Clear OS' file reading cache.
You can create a public void method and make it called by JMH before each:
- trial (
Hi,
Please review an update to the Javadoc of the StAX API from the JSR 173
specification [1], and fix to the implementation to comply with the
specification that the reader's initial event shall be START_DOCUMENT.
JBS: https://bugs.openjdk.java.net/browse/JDK-8069098
webrev: http://cr.openjd
> On 26 Oct 2016, at 05:11, Claes Redestad wrote:
>
> Hi,
>
> does this commentary suffice?
>
> http://cr.openjdk.java.net/~redestad/8168640/webrev.02/
>
+1
> To answer Paul's question about the exact startup gain:
>
> 20 named classes observable with -Xlog:class+load (11
> additional ano
Thank you.
Only one thing left. How can I "burn" the OS' file read cache?
I only know how to do that by allocating a very large amount of memory
based on the information I see in the resource manager (windows) or
system monitor (linux) of the cached I/O and run the program. In this
case, I hav
On 2016-10-26 21:38, Paul Sandoz wrote:
Do you observe that MethodHandleStatics. can take a large proportion of
the VH initialisation time?
Yes, but looking at my startup profiling I also see that that's mostly
due to MethodHandleStatics being the first to touch Integer.parseInt,
which initi
Hello,
On Linux you could use sysctl to drop caches but I guess one Option is to have
a dataset larger than
RAM.http://www.digitalinternals.com/unix/linux-clear-memory-cache/403/
Gruss
Bernd
--
http://bernd.eckenfels.net
On Wed, Oct 26, 2016 at 10:12 PM +0200, "Brunoais" wrote:
Th
On 10/26/2016 09:46 PM, Brunoais wrote:
Thank you.
Only one thing left. How can I "burn" the OS' file read cache?
I only know how to do that by allocating a very large amount of memory
based on the information I see in the resource manager (windows) or
system monitor (linux) of the cached I
You didn't need to Thank you, I'll use it.
On 26/10/2016 21:41, Peter Levart wrote:
On 10/26/2016 09:46 PM, Brunoais wrote:
Thank you.
Only one thing left. How can I "burn" the OS' file read cache?
I only know how to do that by allocating a very large amount of
memory based on the in
On Wednesday, October 26, 2016, Brunoais wrote:
> It is actually based on the premise that:
>
> 1. The first call to ReadableByteChannel.read(ByteBuffer) sets the OS
>buffer size to fill in as the same size as ByteBuffer.
Why do you say that? AFAICT, it issues a read syscall and that will bl
> On Oct 26, 2016, at 6:58 AM, Daniel Fuchs wrote:
>
> With the deprivileging of some JDK modules, classes loaded
> by the Platform class loader should get the same kind of
> loggers than classes loaded by the Boot class loader (null loader).
>
> http://cr.openjdk.java.net/~dfuchs/webrev_816316
Hello,
Please review enclosed fix for:
https://bugs.openjdk.java.net/browse/JDK-8168010
Based on this discussion,
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-September/004934.html
these options are slated for deprecation, only at the documentation level,
and will continue to operate
On 25/10/2016 10:36 PM, Peter Levart wrote:
Hi Claes,
On 10/25/2016 01:09 PM, Aleksey Shipilev wrote:
On 10/25/2016 12:51 PM, Claes Redestad wrote:
Avoiding AtomicBoolean improves startup and footprint for a sample of
small applications:
Webrev: http://cr.openjdk.java.net/~redestad/8168640/w
Hi David,
On 10/27/2016 04:57 AM, David Holmes wrote:
On 25/10/2016 10:36 PM, Peter Levart wrote:
Hi Claes,
On 10/25/2016 01:09 PM, Aleksey Shipilev wrote:
On 10/25/2016 12:51 PM, Claes Redestad wrote:
Avoiding AtomicBoolean improves startup and footprint for a sample of
small applications
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8168205/webrev.00/index.html
If -cp is not specified and -m is not specified, the builtin system
class loader will default the class path to the current working
directory. If -m is specified, no -cp and CLASSPATH environment
variable is
Did you read the C code?
Have you got any idea how many functions Windows or Linux (nearly all
flavors) have for the read operation towards a file?
I have already done that homework myself. I may not have read JVM's
source code but I know well that there's functions on both Windows and
Linux
26 matches
Mail list logo
