On Thu, 18 Aug 2022 09:32:54 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/share/code/compiledMethod.cpp line 128:
>>
>>> 126: if (old_status < new_status) {
>>> 127: if (old_status == not_enqueued) {
>>> 128:
>>>
On Thu, 18 Aug 2022 12:42:48 GMT, Matthias Baesken wrote:
> Another MultiByteToWideChar / malloc case I just saw
> https://github.com/openjdk/jdk/blob/master/src/java.instrument/windows/native/libinstrument/EncodingSupport_md.c#L79
> shouldn't there be the free call after line 80 ?
I think you
On Thu, 18 Aug 2022 12:30:57 GMT, Alan Bateman wrote:
>> There seems to be a case where utf_util.c getWideString might leak memory in
>> an early return.
>
> src/jdk.jdwp.agent/share/native/libjdwp/utf_util.c line 346:
>
>> 344: if (MultiByteToWideChar(codePage, 0, str, len, wstr, wlen) ==
On Thu, 18 Aug 2022 11:51:52 GMT, Matthias Baesken wrote:
> There seems to be a case where utf_util.c getWideString might leak memory in
> an early return.
src/jdk.jdwp.agent/share/native/libjdwp/utf_util.c line 346:
> 344: if (MultiByteToWideChar(codePage, 0, str, len, wstr, wlen) == 0)
There seems to be a case where utf_util.c getWideString might leak memory in an
early return.
-
Commit messages:
- JDK-8292595
Changes: https://git.openjdk.org/jdk/pull/9918/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=9918=00
Issue:
On Thu, 18 Aug 2022 08:57:19 GMT, Dean Long wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Cleanup comment
>
> src/hotspot/share/code/compiledMethod.cpp line 128:
>
>> 126: if (old_status < new_status)
On Thu, 18 Aug 2022 08:18:27 GMT, Axel Boldt-Christmas
wrote:
>> The proposal is to encapsulate the nmethod mark for deoptimization logic in
>> one place and only allow access to the `mark_for_deoptimization` from a
>> closure object:
>> ```C++
>> class DeoptimizationMarkerClosure : StackObj
On Thu, 18 Aug 2022 08:18:27 GMT, Axel Boldt-Christmas
wrote:
>> The proposal is to encapsulate the nmethod mark for deoptimization logic in
>> one place and only allow access to the `mark_for_deoptimization` from a
>> closure object:
>> ```C++
>> class DeoptimizationMarkerClosure : StackObj
> The proposal is to encapsulate the nmethod mark for deoptimization logic in
> one place and only allow access to the `mark_for_deoptimization` from a
> closure object:
> ```C++
> class DeoptimizationMarkerClosure : StackObj {
> public:
> virtual void marker_do(Deoptimization::MarkFn mark_fn)
