Does a file read from a Java application invoke a system call?

My understanding is that a user application requesting a file system path (eg. /aFile) will invoke the File System and get back the virtual address of the requested file. Then the application will attempt a read/write operatio开发者_如何学Gon with that address as argument, that as a CPU instruction? On execution of the read command the Memory Management Unit will translate that address into the phisical address, looking into a page table. In case the user has not privilege to access that memory location (where is that information carried?) the operation is aborted. Otherwise, if the physical address page is found in memory, the read/write operation is carried on it, otherwise the page is brought in from disk and the operation is repeated.

So, there seems to be no system call at all. Could someone correct possible mistakes in the above procedure detail?

(typically) when you open/read/write a file in Java, a call is made to the OS kernel , aka. a system call,for opening/read/write that file. How that is done and the memory management involved is entierly in the hands of the kernel, but eventually bytes read from the file is copied back to a buffer supplied through the system call.

In the very first sentence (invoke the filesystem) that implies a system call since it must of necessity transfer controller to the kernel....

What you are wondering about is operating system design. Many approaches are available and by having the file system abstraction on top of the file abstraction (everything is a file consisting of a stream of bytes) you can do quite a lot without having to change the abstraction.

Just think how different an operating system must treat a RAM disk, compared to a firewire drive, compared again to a Windows network share. The file abstraction is the same.

Now, if you want to actually KNOW what happens, I can strongly recommend downloading and installing OpenSolaris and learning how to work with dtrace. It allows you to ask the system what it does all the way down from your main method to the individual drivers on top of the physical hardware.

What you are describing is Memory Mapped IO which is by no means the only way or even the standard way. And even in this scenario system calls happen although they might be behind the back of the application.

When you have a page fault, i.e. a piece of memory is missing, it will still be the kernel being notified to do all the magic to get the pages into memory from the block device. There is something that needs to figure out from which device to get the info. With software raid this can be very convoluted, with others it can be a simple as configuring a DMA transfer and let it rip. Maybe there are chipsets which can do this on their own under certain circumstances, but certainly not all.

It is not because your program is not doing them that there are no "system calls". However such an abstraction allows the kernel specialist more freedom in squeezing the last ounce of performance from the hardware.