RFR(S): 8138890: C1: Ambiguous operator delete

[Volker Simonis]

Hi Martin,

we have:
class LIRGenerator: public InstructionVisitor, public BlockClosure

and:

class BlockClosure: public CompilationResourceObj

class CompilationResourceObj ALLOCATION_SUPER_CLASS_SPEC {
 public:
  void* operator new(size_t size) throw() { return
Compilation::current()->arena()->Amalloc(size); }
  void* operator new(size_t size, Arena* arena) throw() {
    return arena->Amalloc(size);
  }
  void  operator delete(void* p) {} // nothing to do
};

class InstructionVisitor: public StackObj

class StackObj ALLOCATION_SUPER_CLASS_SPEC {
 private:
  void* operator new(size_t size) throw();
  void* operator new [](size_t size) throw();
#ifdef __IBMCPP__
 public:
#endif
  void  operator delete(void* p);
  void  operator delete [](void* p);

Now you declare new "new()" and "delete()" operators in the LIRGenerator
which will actually hide the corresponding operators from the base classes.
You also provide no implementation for the new operators in LIRGenerator.
So which new/delete operators will be actually used for allocating new
LIRGenerator instances?

OK, wait. As far as I can see, LIRGenerator is never dynamically allocated,
right? In that case it should be a StackObj and you could probably solve
the problem with "using" directives (e.g. using StackObj::operator new,
...). Have you tried that?

Regards,
Volker


On Wed, Oct 7, 2015 at 4:55 PM, Mikael Gerdin <mikael.gerdin at oracle.com>
wrote:

> On 2015-10-07 16:17, Doerr, Martin wrote:
>
>> Hi,
>>
>> that’s a good question J
>>
>> I can only remember that there were problems with some old compilers.
>>
>> Anyway, xlC 12.1 can deal with the private delete operators.
>>
>
> If that's the case, can we also get rid of the workaround in
> allocation.hpp?
>
> Thanks
> /Mikael
>
>
>> Here’s the new webrev:
>>
>> http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.01
>>
>> Best regards,
>>
>>    Martin
>>
>> *From:*Christian Thalinger [mailto:christian.thalinger at oracle.com]
>> *Sent:* Mittwoch, 7. Oktober 2015 03:32
>> *To:* Doerr, Martin
>> *Cc:* hotspot compiler
>> *Subject:* Re: RFR(S): 8138890: C1: Ambiguous operator delete
>>
>>     On Oct 6, 2015, at 3:56 AM, Doerr, Martin <martin.doerr at sap.com
>>     <mailto:martin.doerr at sap.com>> wrote:
>>
>>     Hi,
>>
>>     xlC on AIX rejects to compile LIRGenerator and
>>     RangeCheckEliminator::Verification due to ambiguous operator delete
>>     which gets inherited from multiple base classes.
>>
>>     This change is a prerequisite for our C1 on PPC64 contribution.
>>
>>     Webrev is here:
>>
>>
>> http://cr.openjdk.java.net/~mdoerr/8138890_c1_ambiguous_delete/webrev.00
>>
>> Let me ask my question here:  why do you need the delete methods to be
>> public on AIX?
>>
>>
>>
>> Please review this change.  I need a sponsor, please.
>>
>> Best regards,
>>
>>    Martin
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151007/fa605327/attachment.html>