On 11/22/17 4:48 AM, Erik Österlund wrote:
Hi,
Some replies...
On 2017-11-21 18:36, Daniel D. Daugherty wrote:
Thanks for keeping all the OpenJDK aliases!
On 11/21/17 12:24 PM, coleen.phillim...@oracle.com wrote:
On 11/21/17 11:28 AM, Daniel D. Daugherty wrote:
On 11/20/17 3:12 PM, coleen.phillim...@oracle.com wrote:
I can't find the caller of threads_do_smr.
I'm guessing that's used by the GC code that depends on Thread-SMR...
They should add this API when the add the use of it then. I don't
see it in any sources.
We'll see what Erik wants to do...
The new iterators should be more than enough, so that closure-based
API is not going to be missed when removed.
I will delete it in the wrap up round.
If these functions xchg_smr_thread_list, get_smr_java_thread_list,
inc_smr_deleted_thread_count are only used by thread.cpp, I think
they should go in that file and not in the .inline.hpp file to be
included and possibly called by other files. I think they're
private to class Threads.
I have a vague memory that some of the compilers don't do inlining
when
an "inline" function is in a .cpp. I believe we want these functions
to be inlined for performance reasons. Erik should probably chime in
here.
I don't see why this should be. Maybe some (older) compilers
require it to be found before the call though, but that can still be
accomplished in the .cpp file.
Again, we'll see what Erik wants to do...
I don't mind. Either file works for me. For me it's more intuitive if
inline member function definitions are in the .inline.hpp files. But
if there are strong forces to move this to the cpp file, then sure.
I prefer inline member function definitions in the .inline.hpp files.
(There might even be a style guide note about this...)
Coleen, are you okay if we leave them there?
Dan
Thanks,
/Erik
