My first builds ran to completion yesterday. It’s slow: the 32-bit one took nearly four hours and the 64-bit one a little over six — and this is on a quad 2.5GHz G5! I don’t have exclusive use of the machine though so I suppose other stuff may have been running in the meantime.
The next step is IcedTea integration. My tree is currently an odd hybrid of b17 with b22’s hotspot/src dropped in, and with all the build system changes between b17 and b23 I’ll basically be starting the port from scratch. This is possibly a good thing, because I want to switch from using ARCH_DATA_MODEL to using setarch, but it’s a pain nontheless. I plan to wait until the IcedTea guys have upgraded to b23 and sync my tree on that, remake all the build system patches and then import everything into IcedTea.
I have plenty to do in the meantime. I’ve been doing an audit of dodgy code while builds were running yesterday, basically looking for Unimplemented()s where they shouldn’t be and of course the ubiquitous XXX_EVIL_EVIL_EVIL. This is the state of my to do list:
- Contended locks
- The bit that handles locking and unlocking for synchronized native methods cannot cope when the lock is contended.
- Relocations
- The assembler doesn’t support relocations; if the garbage collector moves generated code then absolute addresses that reference other generated code will become invalid. I’m not sure if this matters currently.
- Atomic copies
Copy::conjoint_jlongs_atomic()is not atomic on 32-bit. The other atomic copies are questionable too, but that one definitely doesn’t do what it says on the tin.- Stack args
- The part of the signature handler that passes arguments to native methods on the stack is untested on 64-bit.
- Unimplemented stuff
- A brief and inexhaustive list: stack overflow checks, stack banging (whatever that is), JVMTI, JDI, profiling, prefetch, a JIT.
So do I understand that your jvm is now being used to run javac and then build the jdk? If so awesome!
The reason you are getting away without relocations is that the code you are generating (frame manager, stubs and misc. pieces) is never relocated. Without relocations you can’t get the compilers to work. Your reasoning about why/how relocs are needed is not correct either. The garbage collector never moves code. However code can have instructions with embedded oops which can move. There are also oops that are in the codeblob but not in the code stream. The compilers also must have relocs because the code is generated into a temp buffer and then relocated into the final position in the code cache.
Stack banging is touching stack pages to get an early segv for a stack overflow before you have no stack space available to recover. Generally we touch a few pages deeper than the current frame.
My jvm is now being used to run javac and then build the jdk :)
Am I correct in thinking that only oops are garbage collected?
yes. Only oops are gc’d. Compiled methods can be reclaimed but not by the garbage collector.