
<html><head></head><body>To add a little more detail, I could move the change up into is_objArray(), but I don't want to expose it to any non-assert paths. Therefore I could do 2 different impls there, guarded by #ifdef ASSERT but I don't think it's a good idea to behave differently under ASSERT, that kindof defeats the point of assert, right?<br><br>What do you think ?<br><br>Roman<br><br><br><div class="gmail_quote">Am 17. April 2019 18:59:09 MESZ schrieb Roman Kennke <rkennke@redhat.com>:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> Various code paths in oopDesc, Klass and their subclasses assert<br> something that fetches the object's _klass field. With upcoming<br> Shenandoah's changes this is not always safe and requires an additional<br> indirection.<br><br> The trouble here is that we can, for example, call<br> Klass::oop_oop_iterate() with a pre-resolved Klass*, instead of<br> oopDesc::oop_iterate() which would call oopDesc::klass() on its own,<br> which would be racy on some GC internal call paths, but we can't<br> (currently) control some calls to klass() further down the call stack<br> (all in asserts).<br><br> We'd also like a way to ensure that non-GC calls to klass() are sane.<br><br> Bug:<br> <a href="https://bugs.openjdk.java.net/browse/JDK-8222545">https://bugs.openjdk.java.net/browse/JDK-8222545</a><br> Webrev:<br> <a href="http://cr.openjdk.java.net/~rkennke/JDK-8222545/webrev.00/">http://cr.openjdk.java.net/~rkennke/JDK-8222545/webrev.00/</a><br> Testing:<br> hotspot_gc_shenandoah with and without the prototype, hotspot/tier1<br><br> The change introduces only two ASSERT-level GC-interfaces, and afaict,<br> this with JDK-8222537 will be all that we need for the upcoming<br> elimination of forward pointers in Shenandoah. Notice that one assert in<br> objArrayKlass is strengthened from is_array() to is_objArray(), but that<br> seems only sane in that context.<br><br> Can I please get reviews?<br></blockquote><br>This looks very awkward to me. Using:<br><br>Universe::heap()->safe_klass(obj)->is_objArray_klass()<br><br>instead of the obvious:<br><br>obj->is_objArray()<br><br>is very unintuitive. Can this not be handled inside is_objArray (and <br>is_typeArray) ?<br></blockquote><br>Not really. Then it would get exposed to many more code paths, most of <br>which don't actually need it/don't want it, and many of which are <br>outside of asserts, and rely on the usual klass() with the sanity assert <br>there instead. I am open for suggestions, but it would have to be <br>restricted to ASSERT code IMO, and ideally with as few as possible GC <br>interface additions.<br><br>Roman<br></pre></blockquote></div><br>-- <br>Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.</body></html>