Hello Chris,
I'm supporting you with this decision.
PS: For people who want SA scripting -
One thing I experimented with a long time ago -
has been exporting of some SA capabilities to jython.
This might be the way to go.
-Dmitry
On 11.12.19 05:52, Chris Plummer wrote:
> Hi,
>
> I like to p
Hi Richard,
On 11/12/2019 7:45 am, Reingruber, Richard wrote:
Hi,
I would like to get reviews please for
http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.3/
Corresponding RFE:
https://bugs.openjdk.java.net/browse/JDK-8227745
Fixes also https://bugs.openjdk.java.net/browse/JDK-82
Hi,
IMHO we need to export all packages in SA if we do not provide new API for SA.
sa.js in jdk.hotspot.agent could access all SA classes until JDK 8 (before
Jigsaw), so we could make various functions if we need.
OTOH we cannot know what classes are needed by the SA users. All packages in
jdk
On 12/10/19 9:56 PM, Yasumasa Suenaga wrote:
On 2019/12/11 14:39, Krystal Mok wrote:
Hi Yasumasa,
That's a very nice idea. Basically what you're asking for is exposing
the Command interface [1] so that plugins can implement it and get
dynamically loaded / registered into CLHSDB / HSDB, right?
It probably would not be that hard to
get SA to load a .class file and call some init function in it,
which in turn could register commands. There is already a
CommandProcessor.registerCommand() for adding _javascript_ commands.
It can easily be overloaded to add
On 2019/12/11 14:39, Krystal Mok wrote:
Hi Yasumasa,
That's a very nice idea. Basically what you're asking for is exposing the
Command interface [1] so that plugins can implement it and get dynamically
loaded / registered into CLHSDB / HSDB, right?
Yes, but we also need proxy API to access i
Hi Yasumasa,
That's a very nice idea. Basically what you're asking for is exposing the
Command interface [1] so that plugins can implement it and get dynamically
loaded / registered into CLHSDB / HSDB, right?
[1]:
http://hg.openjdk.java.net/jdk/jdk/file/c71ec1f09f21/src/jdk.hotspot.agent/share/cl
Hi Chris,
It's a sad proposal, but I agree with you. To maintain SA in JS is difficult
since Jigsaw.
However I want SA to implement pluggable feature.
I use custom script to list compiled codes in CodeCache.
I guess other troubleshooters also want similar feature (via jsload) in future
if they
Thank you very much for the work on the JS support in SA, Sundar! I really
loved it and depended on it. That's why back in the day when the JS support
was broken from time to time I'd get affected and annoyed and send fixes
for them...
A bit of suggestion: I still see a lot of value for having a p
Hi Kris,
Glad to hear that someone used JS interface of SA :) Quick prototyping +
debugger interactive scripting were the goals of JS interface! As you
mentioned, given the current state of SA JS interface, it has to be
removed :(
Thanks
-Sundar
On 11/12/19 8:56 am, Krystal Mok wrote:
Hi
Hi Chris,
Thanks for the proposal. I used to be one of the few heavy users of jsload
/ jseval in CLHSDB back in the JDK6 to JDK8 era. The way I used to use it
is to quickly prototype new functionality in JS and later bake it into Java
code, and also for exploring heap dumps beneath the existing co
Hi,
I like to propose the removal of SA javascript support. Few people even
realize this support exists, and hopefully even fewer are using it since
I'd like to remove it. Since I'm new to this myself, let me first
explain what I know about it's existence, and then explain why I want to
remov
Hi,
I would like to get reviews please for
http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.3/
Corresponding RFE:
https://bugs.openjdk.java.net/browse/JDK-8227745
Fixes also https://bugs.openjdk.java.net/browse/JDK-8233915
And potentially https://bugs.openjdk.java.net/browse/JDK-82
Hi Serguei,
> Do we need to check if the (limit - memLimit) value is negative?
> The same question is for getFreeSwapSpaceSize():
> memSwapLimit - memLimit - (memSwapUsage - memUsage)
>
> and getFreeMemorySize():
>101 return limit - usage;
I don't think we nee
Hi David,
> Please file a follow up RFE to look into this.
I created an issue to follow this up [1]
[1] https://bugs.openjdk.java.net/browse/JDK-8235681
Thank you,
Daniil
On 12/10/19, 2:11 AM, "David Holmes" wrote:
On 10/12/2019 5:31 am, Daniil Titov wrote:
> Hi David,
>
>
On 10/12/2019 5:31 am, Daniil Titov wrote:
Hi David,
So we never try to access the uninitialized counters.cpus array which is
good but we still return garbage for counters.jvmTicks and
counters.cpuTicks - surely that should have been noticeable?
It only affected the first time the
16 matches
Mail list logo
