On Thu, 4 Jan 2024 01:31:46 GMT, David Holmes wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [028ec7e](https://github.com/openjdk/jdk/commit/028ec7e744f06cd8429b7b74d7b6f7020133aa94)
> from the [jdk](https://github.com/openjdk/jdk/) repository.
>
> The commit being bac
On Thu, 4 Jan 2024 07:17:30 GMT, Alan Bateman wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed JDK23 specific change to Compilerp[erfmap
>
> Marked as reviewed by alanb (Reviewer).
Thanks for the review @Al
On Fri, 5 Jan 2024 19:06:34 GMT, Chris Plummer wrote:
>> In threadControl.c, at build time you can decide to keep track of thread
>> names by compiling with "#define DEBUG_THREADNAME". If this is also a debug
>> build, some extra debugging functions are included in the build, including
>> "dum
On Fri, 5 Jan 2024 18:39:25 GMT, Serguei Spitsyn wrote:
> Looks good. Q: Do you want to keep the debugging code under `#ifdef ...
> #endif`?
Yes. The "#ifdef DEBUG_THREADNAME" is something that I want the user to have to
manually enable at build time to avoid the memory and performance impact.
> In threadControl.c, at build time you can decide to keep track of thread
> names by compiling with "#define DEBUG_THREADNAME". If this is also a debug
> build, some extra debugging functions are included in the build, including
> "dumpThread(ThreadNode *node)". These are intended to be called
On Thu, 4 Jan 2024 02:06:28 GMT, Chris Plummer wrote:
> In threadControl.c, at build time you can decide to keep track of thread
> names by compiling with "#define DEBUG_THREADNAME". If this is also a debug
> build, some extra debugging functions are included in the build, including
> "dumpThr
On Thu, 4 Jan 2024 02:06:28 GMT, Chris Plummer wrote:
> In threadControl.c, at build time you can decide to keep track of thread
> names by compiling with "#define DEBUG_THREADNAME". If this is also a debug
> build, some extra debugging functions are included in the build, including
> "dumpThr
On Thu, 4 Jan 2024 02:00:24 GMT, Chris Plummer wrote:
> Use "cause" argument when rethrowing an exception. See CR for details on how
> this helps.
>
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
>
> I'd like to push this as a trivial change.
This pull request has now bee
On Thu, 4 Jan 2024 02:06:28 GMT, Chris Plummer wrote:
> In threadControl.c, at build time you can decide to keep track of thread
> names by compiling with "#define DEBUG_THREADNAME". If this is also a debug
> build, some extra debugging functions are included in the build, including
> "dumpThr
On Thu, 4 Jan 2024 02:00:24 GMT, Chris Plummer wrote:
> Use "cause" argument when rethrowing an exception. See CR for details on how
> this helps.
>
> Tested with all of tier1, and also ran tier2 and tier4 svc tests.
>
> I'd like to push this as a trivial change.
Thanks for the reviews David
On Wed, 20 Dec 2023 11:16:03 GMT, Suchismith Roy wrote:
>> J2SE agent does not start and throws error when it tries to find the shared
>> library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load
>> fails.It fails to identify the shared library ibm_16_am
On Thu, 4 Jan 2024 08:01:57 GMT, Denghui Dong wrote:
> Hi,
>
> Please help review this patch that fixes the failures of
> FullGCHeapDumpLimitTest.java caused by passing other gc flags.
>
> Thanks.
This pull request has now been integrated.
Changeset: 3dc4bd85
Author:Denghui Dong
URL:
On Fri, 5 Jan 2024 02:22:45 GMT, Denghui Dong wrote:
>> Hi,
>>
>> Please help review this patch that fixes the failures of
>> FullGCHeapDumpLimitTest.java caused by passing other gc flags.
>>
>> Thanks.
>
> Denghui Dong has updated the pull request incrementally with one additional
> commit s
On Fri, 5 Jan 2024 02:22:45 GMT, Denghui Dong wrote:
>> Hi,
>>
>> Please help review this patch that fixes the failures of
>> FullGCHeapDumpLimitTest.java caused by passing other gc flags.
>>
>> Thanks.
>
> Denghui Dong has updated the pull request incrementally with one additional
> commit s
On Thu, 21 Dec 2023 10:01:04 GMT, Thomas Stuefe wrote:
>>> > > What happens if we accidentally attempt to load a "real" static
>>> > > library, which is also named *.a? Would dlopen() then crash? What would
>>> > > happen?
>>>
>>> > I don't think the problem is with *.a . They would load as th
15 matches
Mail list logo
