Re: RFR: 8227269: Slow class loading when running JVM in debug mode

Hi Coleen, >>> I'll have a look at this, although it might not be for a few days. In >>> the meantime, maybe you can describe your new implementation in >>> classTrack.c so it's easier to look through the changes. >> Sure. >> >> The purpose of this class-tracking is to be able to determine the >>

Re: Removal of SA javascript support

Hi, Sundar, I agree with you in general, but I want to extend SA in some case. I just want to add gateway to SA. So I proposed to add some classes in jdk.hotspot.agent for exporting. It does not mean to maintain all SA classes for it. I think that the user who want to use it should use it by own

Re: Removal of SA javascript support

Hi, I am going to reiterate. This will lead to maintenance nightmare! Any "Unsupported Java API" is still an API! Remember Unsafe? Once blessed in any form, it is very difficult to remove. Exposing hotspot VM internals as a Java API is very bad idea. No, not even as "unsupported API". Exposi

RFR: CSR: VM_HeapDumper hits assert with bad dump_len

Hi, Please review this draft of the CSR for jdk8u: VM_HeapDumper hits assert with bad dump_len CSR: https://bugs.openjdk.java.net/browse/JDK-8235300 Thanks, Denghui Dong

Re: Removal of SA javascript support

Hi Chris, Can we treat (part of) jdk.hotspot.agent like jdk.unsupported module? jdk.unsupported exports unspec'd API like Unsafe. If we do so, we might need to separate SA API into exported class and internal class. I've proposed to export all SA packages in JDK-8157947, but it was rejected.

RFR: JDK-8235846: Improve WindbgDebuggerLocal implementation

Hi all, Please review a fix for https://bugs.openjdk.java.net/browse/JDK-8235846 webrev: http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_improve/webrev.01/ Main goal of the change is to improve error reporting (we have several bugs and need at least COM error codes for WinDbg calls). Also the

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

On 12/19/19 5:45 AM, Roman Kennke wrote: Hi Chris, I'll have a look at this, although it might not be for a few days. In the meantime, maybe you can describe your new implementation in classTrack.c so it's easier to look through the changes. Sure. The purpose of this class-tracking is to b

Re: Removal of SA javascript support

Hi Yasumasa, I've had similar thoughts about how to extend clhsdb. Why not export everything since what we would export is not part of a spec, and the javascript support had the same issue of potentially breaking when the SA API changed. But maybe this type of unspec'd API exporting is consid

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

Alright, the perfectionist in me got me. I am implementing the even more efficient ~O(1) class tracking. Please hold off reviewing for now. Thanks,Roman Hi Chris, > >> I'll have a look at this, although it might not be for a few days. In >> the meantime, maybe you can describe your new implemen

Re: RFR(s): 8235912: JvmtiBreakpoint remove oops_do and metadata_do

Hi Serguei, On 12/19/19 5:33 AM, serguei.spit...@oracle.com wrote: Hi Robbin, The fix looks good to me. At least, I do not see any issues with it. Thank you for removing the unused code! Thanks! Could you be more precise about on what jvmti/jdi tests you run? For good test coverage we need

Re: RFR: 8227269: Slow class loading when running JVM in debug mode

Hi Chris, > I'll have a look at this, although it might not be for a few days. In > the meantime, maybe you can describe your new implementation in > classTrack.c so it's easier to look through the changes. Sure. The purpose of this class-tracking is to be able to determine the signatures of unl

Re: Removal of SA javascript support

Hi, I think we can provide API for SA as following: Patch: http://cr.openjdk.java.net/~ysuenaga/sa-api/webrev/ Plugin examples: browse: http://cr.openjdk.java.net/~ysuenaga/sa-api/plugin-examples/ download: http://cr.openjdk.java.net/~ysuenaga/sa-api/plugin-examples.tar.gz I think J