Hi Fairoz,
Looks good!
I want you to backport this change to both jdk11u and 8u.
Thanks,
Yasumasa
On 2019/12/12 12:10, Fairoz Matte wrote:
Hi,
Please review this small change,
Updating error handling, to make sure "lib_base_diff = 0" is still a valid
scenario even after
Hi Bob, David, Mandy, and Serguei,
Thank you for reviewing this change!
Best regards,
Daniil
On 12/11/19, 9:21 AM, "Bob Vandette" wrote:
Yes, I defer to Mandy on the best way to express the various Java
exceptions.
I’m ok with the changes.
Thanks for getting this done for
Hi,
Please review this small change,
Updating error handling, to make sure "lib_base_diff = 0" is still a valid
scenario even after calc_prelinked_load_address() call.
JBS - https://bugs.openjdk.java.net/browse/JDK-8235637
Webrev - http://cr.openjdk.java.net/~fmatte/8235637/webrev.00/
This
I discussed with Kris about this in OpenJDK Committers' Workshop last year.
In case of .NET Core, SOS is provided to integrate runtime debugging feature to
native debugger.
If same feature will be provided, I'm very happy!
For example, GDB and WinDbg provides remote debug server.
If (CL)HSDB
Hi Dmitry,
Thanks for your comment!
On 2019/12/12 0:34, Dmitry Samersoff wrote:
Hello Yasumasa,
Please,
1. Consider to use mmap for reading elf sections.
Did you pointed `read_section_data()`?
lib->eh_frame.data = read_section_data(lib->fd, , sh);
I do not change implementation of
Hi Daniil,
Got it, thanks!
Serguei
On 12/11/19 15:33, Daniil Titov wrote:
Hi Serguei,
Thank you for reviewing this change.
Just wanted to add that the only "volatile" metrics are "usage" ones (
memoryUsage and
memoryAndSwapLimit). The "limit" metrics (memoryLimit and memoryAndSwapLimit)
Hi Serguei,
Thank you for reviewing this change.
Just wanted to add that the only "volatile" metrics are "usage" ones (
memoryUsage and
memoryAndSwapLimit). The "limit" metrics (memoryLimit and memoryAndSwapLimit)
are set
when the container starts and are not subjects to change. The only
Typo fixed...
.. that the only "volatile" metrics are "usage" ones ( memoryUsage and
*memoryAndSwapUsage*).
Best regards,
Daniil
On 12/11/19, 3:33 PM, "Daniil Titov" wrote:
Hi Serguei,
Thank you for reviewing this change.
Just wanted to add that the only "volatile"
Hi Daniil,
One my concerns was a non-atomic read of multiple metrics before comparison.
It creates a potential to get a mismatch in result.
However, the probability to get a negative value is pretty low, I think.
The other concern (if incorrect metrics are returned) is covered by
JDK-8235522.
Regarding maintaining hotspot data structures in SA, I think we often
break it without knowing, especially when we are adding data structures
that are not currently exposed by SA.
Does anyone have a sense of the state of SA in newer versions of the
JDK. Is SA still doing what you expect, or
On 12/12/2019 1:07 am, Reingruber, Richard wrote:
Hi David,
> Most of the details here are in areas I can comment on in detail, but I
> did take an initial general look at things.
Thanks for taking the time!
Apologies the above should read:
"Most of the details here are in areas I
Hi Chris,
The change looks good to me.
Best regards,
Daniil
On 12/4/19, 5:39 PM, "serviceability-dev on behalf of Chris Plummer"
wrote:
Can I get one more review please?
thanks,
Chris
On 12/3/19 1:10 PM, serguei.spit...@oracle.com wrote:
> Hi Chris,
>
Yes, I defer to Mandy on the best way to express the various Java exceptions.
I’m ok with the changes.
Thanks for getting this done for JDK14!
Bob.
> On Dec 11, 2019, at 12:12 PM, Daniil Titov wrote:
>
> Hi Serguei,
>
> Thank you for your comments. I will correct this nits before pushing the
Hi Serguei,
Thank you for your comments. I will correct this nits before pushing the
changes.
Hi Bob and David,
> [Mandy Chung]
>> I reviewed Metrics and Subsystem in this version.
>> I don't need to see a new webrev.
As I understood Mandy finished reviewing this fix. Just wanted to confirm
Hello Yasumasa,
Please,
1. Consider to use mmap for reading elf sections.
2. Please move all platfrom-specific parts of native code to a separate
file/directory. Current patch will brake AARCH64 build.
3. I didn't find any tests here. How did your test the changes?
libproc_impl.c
131: If is
Hi David,
> Most of the details here are in areas I can comment on in detail, but I
> did take an initial general look at things.
Thanks for taking the time!
> The only thing that jumped out at me is that I think the
> DeoptimizeObjectsALotThread should be a hidden thread.
>
> +
Sundar,
Supporting hotspot data structure in SA is already a maintenance
nightmare ;)
So we can consider to provide high level API, like find_class_by_name to
script writer.
It allows anybody who are interesting with quick prototyping write his
own program on top of SA with any language they
Replacing one scripting language with another (jython) does not solve
anything. You'd still face the same issues - accessing module private
stuff from SA module from scripts. Besides you'll have a new problem in
addition. How to bundle jython? We've been using bundled scripting
engine
Effectively you're asking for SA as API. I don't think that is a good
idea. That implies supporting hotspot data structures as Java *API*.
That will be maintainability nightmare - we've to keep tracking hotspot
data structures in SA code. That itself is problematic. API would be
next level
19 matches
Mail list logo
