On 28/04/2016 14:24, Michael Rasmussen wrote:
Just a quick mail to say that can_generate_early_class_hook_events (new
capability) is in jdk9/hs so it should make it into JDK 9 master and into a
promoted build soon (maybe jdk-9+117 or jdk-9+118).
-Alan
Thank you very much!
Looking forward to tr
> Just a quick mail to say that can_generate_early_class_hook_events (new
> capability) is in jdk9/hs so it should make it into JDK 9 master and into a
> promoted build soon (maybe jdk-9+117 or jdk-9+118).
>
> -Alan
Thank you very much!
Looking forward to trying it out
On 08/04/2016 14:50, Michael Rasmussen wrote:
:
So this would mean the agent would be able to get CLFH for _all_ classes,
even Object, String, Class etc, that are the very first to be loaded, and
potentially instrument the bytes for those classes as well?
Of course still following the rules abou
On 8 April 2016 at 15:58, Alan Bateman wrote:
> I think it would be better if we could post CFLH events in the primordial
> phase but this is only possible if agents opt-in via a new capability, maybe
> can_generate_early_class_hook_events that would have to be added along with
> can_generate_all_
On 04/04/2016 12:47, Michael Rasmussen wrote:
But retransform in this phase would still be subject to the same
limitations about no structural changes I assume? Meaning no adding of
members etc.
My preferred solution would still be if adding (and changing) Xpatch
would be possible during On
On 04/04/2016 12:47, Michael Rasmussen wrote:
But retransform in this phase would still be subject to the same
limitations about no structural changes I assume? Meaning no adding of
members etc.
My preferred solution would still be if adding (and changing) Xpatch
would be possible during O
But retransform in this phase would still be subject to the same
limitations about no structural changes I assume? Meaning no adding of
members etc.
My preferred solution would still be if adding (and changing) Xpatch would
be possible during OnLoad, as that should solve all my problems.
/Michael
On 04/04/2016 12:09, Michael Rasmussen wrote:
So in order to patch any of the well-known preloaded classes, I will need
to prepatch them, put them in a folder/jar, and then need to ask the user
to specify the -Xpatch jvm option, seeing as I don't have the option to
neither patch them via CFLH, no
So in order to patch any of the well-known preloaded classes, I will need
to prepatch them, put them in a folder/jar, and then need to ask the user
to specify the -Xpatch jvm option, seeing as I don't have the option to
neither patch them via CFLH, nor add -Xpatch myself from jvmti?
If that is the
On 04/04/2016 11:31, Michael Rasmussen wrote:
Hi Alan
Finally had time today to do some testing of can_generate_early_vmstart.
Can you elaborate on which classes I should be able to patch using CFLH
with early_vmstart enabled? From the quick testing I did, it appears that
most of the core java
Hi Alan
Finally had time today to do some testing of can_generate_early_vmstart.
Can you elaborate on which classes I should be able to patch using CFLH
with early_vmstart enabled? From the quick testing I did, it appears that
most of the core java.lang classes do not generate CFLH events? For
in
On 29/03/2016 10:14, Michael Rasmussen wrote:
With the new -Xpatch format, are there any plans to add support for
adding (or modifying) these from JVMTI in the OnLoad phase?
/Michael
Not specifically but you can use -Xpatch in conjunction with
-agentlib/-agentpath.
Also if enable the new can_
With the new -Xpatch format, are there any plans to add support for
adding (or modifying) these from JVMTI in the OnLoad phase?
/Michael
On 28 March 2016 at 20:30, Alan Bateman wrote:
>
> Sorry, it is a bit confusing as we aren't quite done with the transition
> from an older form of a -Xpatch t
OK, sounds like we have a plan.
Currently jsr166 development has no problem with -Xpatch in +111
because we use the old syntax.
On Mon, Mar 28, 2016 at 10:30 AM, Alan Bateman wrote:
>
> Sorry, it is a bit confusing as we aren't quite done with the transition
> from an older form of a -Xpatch to
Sorry, it is a bit confusing as we aren't quite done with the transition
from an older form of a -Xpatch to the new form.
The syntax you see in JEP 261 and in the java -X usage output is the new
form. That works for modules defined to the platform or application
class loaders but doesn't wor
15 matches
Mail list logo
