code for native functions

[bob smith]

Is there a way for me to look at the code for native functions such as this?

public static native long nanoTime();

Thanks.

 

[Daniel Pitts]

Is there a way for me to look at the code for native functions such as this?

public static native long nanoTime();

Thanks.

I believe some JREs are open source (such as OpenJDK), though I'm not
certain. You'd have to look at each of the vendors to find out. That
is where you'd find those source codes.

 

[Arne Vajhøj]

Is there a way for me to look at the code for native functions such as this?

public static native long nanoTime();

No, yes and no.

No - Java only specify what it does - Java does not specify a
specific implementation - it will vary between Java implementations
(both vendor and target OS).

Yes - there are some implementation where the source code
is available. You should be able to get OpenJDK for Linux.

No - you should not do it. Java code that relies on a certain
implementation of that method is very bad code. You should
write your code to the API definition and not assume anything
beyond what that guarantees.

Arne

 

[Roedy Green]

Is there a way for me to look at the code for native functions such as this?

public static native long nanoTime();

back in the early windows days I had a tool called VCommunications
Sourcer that would disassemble 16 bit code. Presumably there exist 32
and 64 bit analogs. I also had a program called Periscope that let me
trace 16 bit code at the assembler level. Again, there aught to exit
32 and 64 bit analogs, though it may be a lost art.

I wrote a 16 bit assembler back in 1985. It was very fiddly work
since there are so many variants on op code formats.

Your best bet is to look at http://jdk6.java.net/download.html and see
if Oracle will let you peek at the C source.

I was puzzling about System.nanotime too. (I think about the oddest
things in that state between sleeping and wakefulness). Does each CPU
core have its own nanocounter hardware? If a thread hops from core to
core, how does nanotime present a consistent value? Does it depend on
what other threads are doing or does it behave almost like true time?

When multiple threads run, on multiple cores and they each note some
external event, will they all assign it the same nanotime?

I like to understand things not with a set of mysterious and
apparently arbitrary lawyerly rules constraining behaviour, but with a
simplified implementation model, from which I can deduce behaviour. I
have not yet explored this, just mused.

 

[Daniel Pitts]

back in the early windows days I had a tool called VCommunications
Sourcer that would disassemble 16 bit code. Presumably there exist 32
and 64 bit analogs. I also had a program called Periscope that let me
trace 16 bit code at the assembler level. Again, there aught to exit
32 and 64 bit analogs, though it may be a lost art.

I wrote a 16 bit assembler back in 1985. It was very fiddly work
since there are so many variants on op code formats.

Your best bet is to look at http://jdk6.java.net/download.html and see
if Oracle will let you peek at the C source.

I was puzzling about System.nanotime too. (I think about the oddest
things in that state between sleeping and wakefulness). Does each CPU
core have its own nanocounter hardware? If a thread hops from core to
core, how does nanotime present a consistent value? Does it depend on
what other threads are doing or does it behave almost like true time?

When multiple threads run, on multiple cores and they each note some
external event, will they all assign it the same nanotime?

See this blog entry:
<https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks>

nanoTime doesn't necessarily use the CPU nanocounter.

I like to understand things not with a set of mysterious and
apparently arbitrary lawyerly rules constraining behaviour, but with a
simplified implementation model, from which I can deduce behaviour. I
have not yet explored this, just mused.

I do the same thing. I like to do deep dive, and have occasionally found
myself in Kernel Source Code to understand how a particular call works.

 

[Arne Vajhøj]

Your best bet is to look at http://jdk6.java.net/download.html and see
if Oracle will let you peek at the C source.

They don't.

And given that the title is "Binary Snapshot Releases" then I don't see
why you would think so.

OpenJDK does just a subdomain away. But there is no guarantee that it
will have the same implementation (even though I consider it likely).

Arne

 

[Roedy Green]

nanoTime doesn't necessarily use the CPU nanocounter.

That makes sense. I was thinking about the ways various CPU cores
change frequencies, go to sleep, get overclocked etc. Threads could
run on all the cores for short periods of time. An instruction counter
on each CPU seemed pretty useless. I could not see how you could
reasonably reconstruct a global time from them.

You'd think a common high frequency counter of standard frequency
would not be rocket science.

 

[Joshua Cranmer ðŸ§]

You'd think a common high frequency counter of standard frequency
would not be rocket science.

Look at the microarchitecture of a modern microprocessor, and you'll
realize that it is a very hard problem. You're asking for effectively a
3GHz clock that presumably doesn't roll over soon--so more than 32 bits.
That means you need a very fast increment circuit, and, to minimize gate
delay, that means high-voltage too. Since you want it to be immune to
the state of the processor, you have to use a high-voltage, high
frequency circuit whether a chip is in high power or low power mode. If
you want it to be shared, it has to be outside every processor core's
power domain. Which means accessing this counter is going to require
going through bus arbitrage mechanisms, which means you have
unpredictable latencies on the order of hundreds of cycles.

Shared, high frequency, low-latency access, predictable frequency. You
can't get all of them. Or even most of them.

 

[Roedy Green]

Shared, high frequency, low-latency access, predictable frequency. You
can't get all of them. Or even most of them.

You might have slow access, but if were at least predictably slow
access might be acceptable. Consider there is software overhead to
examine the clock too.

If it were a 32 bit hardware counter, the CPUs would sample it often
enough to detect it "running backwards" and note in software the
overflow and maintain an effective 64 bit counter (high bits in
software, low bits is hardware).