Dean Long
Dean Long
No, because the number of lines includes header lines.
I just double checked and you're right. It looks like I'm actually running into a different problem. Sometimes the number of lines is incorrectly reported as 0, and that causes...
The line count could be correct in one folder but 0 in another folder. How about if the line count is 0, compute it from the message body?
That sounds like it would work. I was hoping there was a way to force TB to recompute the value.
By the way, I use the "set original message folder" feature to compare folders on different servers or locally. I see that a Microsoft Exchange server includes the header lines...
Now that you are building a separate list of nmethods to deoptimize, what protects that list from nmethods being recycled by other threads? Don't you need to hold the CodeCache_lock?...
It's nmethod::flush() I'm worried about. It uses CodeCache_lock, not Compile_lock. It calls CodeCache::free() to destroy the nmethod.
@fisk, is there any chance that in the future we might figure out how to allow nmethods to be flushed without a safepoint? Maybe with handshakes or some other clever...
If the nmethod shouldn't be on the marked list at certain state transitions, how about adding asserts that check this? Using the same "self looped" trick that the Sweeper removal...
I don't think we need a new RuntimeBlob subclasses. Can't we use the existing AdapterBlob or MethodHandlesAdapterBlob? When changing from nmethod to CodeBlob, don't we need to replace COMPILED_METHOD_LOAD JVMTI...