Understanding the Reference Handler thread

Question

I am continuing my path to deep understanding of Java Thread. Unfortunately my Java Certification didn't cover that part, so the only way of learning is to post a series of dumb questions. With so many years of Java Development, I am sometimes wondering how much I still have to learn :-)

In particular my attention is now with the reference handler thread.

"Reference Handler" daemon prio=10 tid=0x02da3400 nid=0xb98 in Object.wait() [0x0302f000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x1aac0320> (a java.lang.ref.Reference$Lock)
    at java.lang.Object.wait(Object.java:485)
    at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
    - locked <0x1aac0320> (a java.lang.ref.Reference$Lock)

Now some questions are following, for some of them I know the answer, but I am not posting it, because I would like to hear someone else opinions:

1. What is the Reference Handler thread supposed to do ?
2. A thread dump should be considered bottom up, why does the stack trace start with locked, shouldn't the lock statement appears at least after the thread has run ?
3. What does "Native Method" means ?
4. Why "Unknown Source", in which case the thread dump cannot recall the source code ?
5. Lastly the waiting on and locked has the same , why ?

as usual, I kindly ask to answer all the questions, so that I can mark answered.

Answer 1

1. I suspect it handles running finalizers for the JVM. It's an implementation detail and as such not specified in the JVM spec.
2. This only means that the java.lang.ref.Reference$Lock was locked in the method mentioned in the line preceding it (i.e in ReferenceHandler.run().
3. "Native Method" simply means that the method is implemented in native (i.e. non-Java) code (think JNI).
4. Unknown Source only means that the .class file doesn't contain any source code location information (at least for this specific point). This can happen either when the method is a synthetic one (doesn't look like it here), or the class was compiled without debug information.
5. When a thread waits on some object, then it must have locked that object at some point down the call trace, so you can't really have a waiting on without a corresponding locked.