Hi Coleen,
On 15/09/2020 10:19 pm, Coleen Phillimore wrote:
The string in these tests are a legal utf8 but still fail conversion,
The problem is that it expects string A and gets string B - which
suggests that thread-safety problem still exists somehow:
fatal error: String conversion
On Mon, 14 Sep 2020 17:10:26 GMT, Daniel D. Daugherty
wrote:
>> From the spec I'm not clear on exactly what JVMTI_HEAP_REFERENCE_MONITOR is
>> intended to be. Serviceability folk should
>> be giving some input here though.
>
> I've taken a first pass at creating a CSR:
> JDK-8253121 migrate
On Mon, 14 Sep 2020 21:15:00 GMT, Daniel D. Daugherty
wrote:
>> This RFE is to migrate the following field to OopStorage:
>>
>> class ObjectMonitor {
>>
>> void* volatile _object; // backward object pointer - strong root
>>
>> Unlike the previous patches in this series, there are a lot of
On Mon, 14 Sep 2020 17:10:39 GMT, Daniel D. Daugherty
wrote:
>> I don't see anything in the HPROF format description that claims this is a
>> strong root. At a minimum this seems to be a
>> behavioural change that would warrant a CSR request. This also seems to be
>> something that the
On Sat, 12 Sep 2020 23:19:46 GMT, Richard Reingruber wrote:
> Continuing review [1] after transition to Git/Github.
>
> I still cannot reproduce the issue.
>
> RFC on alternatives:
>
> 1. Integrate this change and ignore future JVMTI_ERROR_INVALID_SLOT
> 2. Don't ignore
Hi Richard,
This is on my review list. I'll try to get it reviewed by the end of
this week.
Thanks,
Serguei
On 9/8/20 10:02, Reingruber, Richard wrote:
Hello Marty,
Sure. I'd be happy if Serguei could review the change.
Thanks, Richard.
-Original Message-
From: Marty Thompson
On Tue, 15 Sep 2020 16:43:01 GMT, Daniil Titov wrote:
> The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes()
> when the current thread is in the middle
> of redefining the same class. The change is based on the fix [1] suggested in
> the Jira issue [2] comment.
> [1]
On Tue, 15 Sep 2020 13:34:21 GMT, Richard Reingruber wrote:
> I would like to take a different approach now for fixing this by making sure
> the JVMTI GetLocalObject() call refers to
> one of the recursiveMethod frames on stack.
After a closer look I don't think this is possible. The
On Tue, 15 Sep 2020 19:13:55 GMT, Vipin Sharma wrote:
>> I've only looked at the management files. They look good in general.
>>
>> src/java.management/share/classes/java/lang/management/ClassLoadingMXBean.java
>>
>> 108 * @throws java.lang.SecurityException if a security manager
>> 109
On Tue, 15 Sep 2020 18:14:58 GMT, Serguei Spitsyn wrote:
>> Updated @exception with @throws for core-libs, it fixes all open sub-tasks
>> of JDK-8252536.
>>
>> Open Subtasks part of this fix are:
>> 1. JDK-8252537
>> 2. JDK-8252539
>> 3. JDK-8252540
>> 4. JDK-8252541
>>
>> Previous
Some SA core file testing requires longer timeouts since core files can on
occasion take a very long time to produce on
OSX.
-
Commit messages:
- 8253028: SA core file tests still time out on OSX with "java.io.IOException:
App waiting timeout"
Changes:
On Wed, 9 Sep 2020 19:29:30 GMT, Vipin Sharma wrote:
> Updated @exception with @throws for core-libs, it fixes all open sub-tasks of
> JDK-8252536.
>
> Open Subtasks part of this fix are:
> 1. JDK-8252537
> 2. JDK-8252539
> 3. JDK-8252540
> 4. JDK-8252541
>
> Previous conversation on this:
>
The change fixes a 'deadlock' situation in VM_RedefineClasses::lock_classes()
when the current thread is in the middle
of redefining the same class. The change is based on the fix [1] suggested in
the Jira issue [2] comment.
[1] http://cr.openjdk.java.net/~jiangli/8241390/webrev.00/
[2]
On Fri, 11 Sep 2020 01:08:53 GMT, Daniil Titov wrote:
> The change fixes the regression introduced by
> https://bugs.openjdk.java.net/browse/JDK-8241080.
>
> Method validateAssignment() in com.sun.tools.jdi.ObjectReferenceImpl now
> always retrieves the reference type and that
> requires one
On Tue, 15 Sep 2020 14:15:31 GMT, Daniel D. Daugherty
wrote:
>> Thanks @iignatev for providing the hint that helped finding the cause for
>> the JVMTI_ERROR_INVALID_SLOT
>>
>>
On Tue, 15 Sep 2020 13:34:21 GMT, Richard Reingruber wrote:
>> Continuing review [1] after transition to Git/Github.
>>
>> I still cannot reproduce the issue.
>>
>> RFC on alternatives:
>>
>> 1. Integrate this change and ignore future JVMTI_ERROR_INVALID_SLOT
>> 2. Don't ignore
On Sat, 12 Sep 2020 23:19:46 GMT, Richard Reingruber wrote:
> Continuing review [1] after transition to Git/Github.
>
> I still cannot reproduce the issue.
>
> RFC on alternatives:
>
> 1. Integrate this change and ignore future JVMTI_ERROR_INVALID_SLOT
> 2. Don't ignore
On Mon, 14 Sep 2020 21:15:00 GMT, Daniel D. Daugherty
wrote:
>> This RFE is to migrate the following field to OopStorage:
>>
>> class ObjectMonitor {
>>
>> void* volatile _object; // backward object pointer - strong root
>>
>> Unlike the previous patches in this series, there are a lot of
The string in these tests are a legal utf8 but still fail conversion,
which is unexpected. I'll have a look.
+ if (UTF8::is_legal_utf8((const unsigned char*)utf8_str,
(int)strlen(utf8_str), false)) {
ResourceMark rm;
const char* expected = utf8_str;
char* actual = as_utf8_string(h_obj());
On Mon, 14 Sep 2020 21:15:00 GMT, Daniel D. Daugherty
wrote:
>> This RFE is to migrate the following field to OopStorage:
>>
>> class ObjectMonitor {
>>
>> void* volatile _object; // backward object pointer - strong root
>>
>> Unlike the previous patches in this series, there are a lot of
On Mon, 14 Sep 2020 18:55:38 GMT, Daniel D. Daugherty
wrote:
>> This RFE is to migrate the following field to OopStorage:
>>
>> class ObjectMonitor {
>>
>> void* volatile _object; // backward object pointer - strong root
>>
>> Unlike the previous patches in this series, there are a lot of
On Mon, 14 Sep 2020 21:15:00 GMT, Daniel D. Daugherty
wrote:
>> This RFE is to migrate the following field to OopStorage:
>>
>> class ObjectMonitor {
>>
>> void* volatile _object; // backward object pointer - strong root
>>
>> Unlike the previous patches in this series, there are a lot of
Hi Leonid,
I don’t have access to JCK issues, but thanks for creating it.
Best regards,
Martin
From: leonid.kus...@oracle.com
Sent: Montag, 14. September 2020 23:00
To: Doerr, Martin ; David Holmes
; serviceability-dev@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Cc: Zeller, Arno
This patch implements asynchronous handshake, which changes how handshakes
works by default. Asynchronous handshakes
are target only executed, which they may never be executed. (target may block
on socket for the rest of VM lifetime)
Since we have several use-cases for them we can have many
24 matches
Mail list logo
