RFR: 8203629: Produce events in the JDK without a dependency on jdk.jfr

[Markus Gronlund]

Hi Alan,

Some context might be helpful here:

The real JFR API is located in module jdk.jfr and the API handle there is this class jdk.jfr.Event [1]

There are multiple reasons for choosing an class as the API instead of an interface - most of them are driven by implementation (in the VM) and performance related.

As you can see in [1], the methods we are discussing here are there declared "final". This reflects the fact that we don't want user versions of these methods. We do want the signatures and the schema however so we can rework classes and methods in the VM.

Using a class hierarchy allows us via induction quickly decide (bit check) if a loading class is related to the API (which cannot be done as performant should the solution be based on an interface) and we want to work with invokevirtual and invokespecial but not so much invokeinterface.

So this solution we are discussing here is about how we can extend what we already have in place for JFR to also allow code in java.base to use it.

The main challenge here is with solving the module system inversion in that java.base can't have a compile dependency on the real JFR API located in jdk.jfr:

With the solution proposed by Erik, we extend our JFR VM machinery to also treat jdk.internal.events.Event in the same way as jdk.jfr.Event. Unfortunately, in order to do this, we now can't make the methods in jdk.internal.events.Event "final" since we will need inherit it from jdk.jfr.Event (which implement these methods already in the API proper). Also, there now needs to be careful means in the VM of avoiding jdk.jfr module related symbols when processing java.base events in certain states (for example, a module read link not having been established (yet or at all) etc).

I don’t think we should view jdk.internal.events.Event as an general API but instead it is a means of hooking into the JFR system at runtime, via the VM, avoiding the compile time dependency. 

"Regular code" should work with the jdk.jfr module proper if possible, but for situations that cannot handle that / don't want to add the module import for some reason, this is a JDK internal hook point, that can be used if needed. This is also the reason why it is not exported to other modules in general, it is mainly intended for java.base, since the inversion leave no other alternatives (except moving all jfr code into java.base which I think is probably not an option). 

In addition, nothing in jdk.internal.events.Event strongly couple with jdk.jfr which means it may be put to some other use for alternative implementations that do not have a JFR implementation say.

Hope this clarifies a bit

Thanks
Markus 

[1] https://docs.oracle.com/javase/9/docs/api/jdk/jfr/Event.html 


-----Original Message-----
From: Alan Bateman 
Sent: den 21 juni 2018 09:52
To: Erik Gahlin <erik.gahlin at oracle.com>; hotspot-jfr-dev at openjdk.java.net; core-libs-dev <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: 8203629: Produce events in the JDK without a dependency on jdk.jfr

On 20/06/2018 18:59, Erik Gahlin wrote:
> :
>
>> Also all the methods are empty which makes me wonder if they should 
>> be abstract (as the class is abstract) or whether it should be an 
>> interface.
> Abstract is needed to prevent user from instantiating the class.
>
> The methods need to have a body, otherwise event classes in java.base 
> would need to implement the methods, which would be cumbersome. We 
> like to use a class as it simplifies the implementation if we know all 
> event classes have a common ancestor with java.lang.Object as a parent.
>
> so we can be guaranteed that the class
I'm not sure that I understand the issues here but just to say that jdk.internal.event is not exported so code outside of the JDK cannot directly instantiate instances of classes in that package. Also interfaces can have default methods which may go to your concern about needing to implement each of the 6 methods. Once Event is cleaned up with some javadoc then it will be easier to argue this one way or the other.

-Alan