JDK-8151620 : Compiler runtime entries should use OOPs instead of raw Klass*
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2016-03-10
  • Updated: 2016-12-19
  • Resolved: 2016-04-26
Related Reports
Relates :  
JDK-8141420 - Compiler runtime entries don't hold Klass* from being GCed
Description
Migrate compiler entries from using Klass* to oopDesc*:
JRT_BLOCK_ENTRY(void, OptoRuntime::new_instance_C(Klass* klass, JavaThread* thread))

becomes

JRT_BLOCK_ENTRY(void, OptoRuntime::new_instance_C(oopDesc* mirror, JavaThread* thread))

It should simplify the logic to keep classes alive across safepoints and allows to remove handles to class mirrors added by JDK-8141420.
Comments
I think there is a reason we kept the KlassHandles around. [~coleenp]?
28-04-2016
The approach proposed in this RFE doesn't help much. Since most of the callers don't have mirrors at their hands (because they don't need them), the only viable solution I see is to introduce different runtime entry variants for raw klasses & mirrors and choose the entry depending on the context. It allows to skip creating mirror handles in the entries, but means more logic/code in the compiler itself and (sometimes) in generated code. What I find more disturbing is KlassHandles became useless with PermGen removal, but the code is full of their usages. I'd prefer to see them go away instead.
27-04-2016
I'm not sure if I would call it a "tiny benefit". It might be small in terms of code that can be removed but having handles in all the right places is not trivial. Especially when new code is added.
26-04-2016
I experimented with using mirrors in runtime entries instead of raw Klasses, but it means more generated code for a tiny benefit. Mirror loads become explicit in the generated code, but most of the time they aren't needed (e.g., a klass comes from a constant pool). Closing as "Will Not Fix".
26-04-2016