Re: [omr-dev] How to avoid OMR compiler static instance

["Irwin D'Souza" <dsouzai@xxxxxxxxxx>]

Hi Dibyendu,

I believe the JitConfig is a singleton because it holds some global variables that are used at least in downstream projects such as OpenJ9. The MonitorTable is a singleton because it is a single repository that the compiler can use to get hold of monitors it might need; again, this is something that OpenJ9 uses.

What use case are you considering that would benefit from these objects not being singletons?

Cheers,

Irwin D'Souza
JIT Compiler Developer
IBM Runtime Technologies
Email: dsouzai@xxxxxxxxxx
Phone: 905-413-2956

Dibyendu Majumdar ---05/30/2018 05:43:49 AM---Hi, I was wondering if the singleton instance of OMR can be avoided. I

From: Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx>
To: omr-dev@xxxxxxxxxxx
Date: 05/30/2018 05:43 AM
Subject: [omr-dev] How to avoid OMR compiler static instance
Sent by: omr-dev-bounces@xxxxxxxxxxx

---

Hi,

I was wondering if the singleton instance of OMR can be avoided. I
would like to understand the reasons for this.

For example: in compiler/env/JitConfig.cpp:

TR::JitConfig *
TR::JitConfig::instance()
   {
   return OMR::FrontEnd::singleton().jitConfig();
   }


And in compiler/infra/OMRMonitorTable.cpp:

// singleton
class OMR_EXTENSIBLE MonitorTable
   {
   public:

   static TR::MonitorTable *get() { return _instance; }

   protected:

   static TR::MonitorTable *_instance;


Are there issues I need to be aware of if I wanted to change this?

Thanks and Regards
Dibyendu
_______________________________________________
omr-dev mailing list
omr-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/omr-dev