RFR (S): 8198561: Make oop and narrowOop always have their own class type (original) (raw)

Roman Kennke rkennke at redhat.com
Wed Mar 14 11:27:19 UTC 2018

So where are we with this change?

There's not many places where I can think of possible performance problems. Probably the most crucial ones are the oop/narrowOop/object iterators that are used by GC. OopClosure and subclasses get pointers to oop/narrowOop.. it shouldn't make a difference. Then there's ObjectClosure which receives an oop. Does it make a difference there? Maybe write a little benchmark that fills the heap with many small objects, and runs an empty ObjectClosure over it? If it doesn't show up there, I'm almost sure it's not going to show up anywhere else...

Roman

Hi Coleen,

Thanks for the review. On 2018-02-26 20:55, coleen.phillimore at oracle.com wrote:

Hi Erik, This looks great.   I assume that the generated code (for these classes vs. oopDesc* and juint) comes out the same? I assume so too. Or at least that the performance does not regress. Maybe I run some benchmarks to be sure since the question has been asked. Thanks, /Erik thanks, Coleen On 2/26/18 8:32 AM, Erik Österlund wrote: Hi,

Making oop sometimes map to class types and sometimes to primitives comes with some unfortunate problems. Advantages of making them always have their own type include: 1) Not getting compilation errors in configuration X but not Y 2) Making it easier to adopt existing code to use Shenandoah equals barriers 3) Recognize oops and narrowOops safely in template Therefore, I would like to make both oop and narrowOop always map to a class type consistently. Webrev: http://cr.openjdk.java.net/~eosterlund/8198561/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8198561 Thanks, /Erik

More information about the hotspot-dev mailing list