RFR (S) 8211239: Build fails without JFR: empty JFR events signatures mismatch

[Aleksey Shipilev]

On 10/01/2018 09:49 AM, David Holmes wrote:
>> Any other Reviewers? Would like to unbreak jdk/jdk :)
> 
> Isn't printEmptyType redundant with this change?

Right! Removed here:
  http://cr.openjdk.java.net/~shade/8211239/webrev.03/

> 480             out.write("template <typename T>");
> 
> Why is this now a template class? I don't see T being used.

"Empty" JfrEvent now matches "full" JfrEvent from jfrEvent.hpp:

template <typename T>
class JfrEvent {
 private:
  jlong _start_time;
  jlong _end_time;
  bool _started;
  ...

The "empty" subclasses use the template parameter here:

  out.write("class Event" + event.name + " : public JfrEvent<Event" + event.name + ">");

...and here:

  out.write("  using JfrEvent<Event" + event.name + ">::commit; // else commit() is hidden by
overloaded versions in this class");


> The refactoring to handle the "empty" case within the same logic seems reasonable, though it's not
> immediately obvious to me where the signature mismatch was introduced previously or how the refactor
> prevents that ?

I think the mismatch between full and empty events was always there, I see it up to the original
commit of JFR event generator. But it was not observed until we started to use the multi-parameter
commit() methods in JDK-8196341: http://hg.openjdk.java.net/jdk/jdk/rev/5f931e3e7a63 -- when it
broke the non-JFR build. The surprises like that is why I think we are better generating the same
methods with/without body on full/empty event paths.

Thanks,
-Aleksey