Hi Serguei,
On 28/05/2020 3:12 pm, serguei.spit...@oracle.com wrote:
Hi David,
I've updated the CSR and webrev in place.
The changes are:
- addressed David's suggestion to rephrase StopThread description change
- replaced JVMTI_ERROR_INVALID_OBJECT with JVMTI_ERROR_ILLEGAL_ARGUMENT
- upd
Hi Alex,
It'd be nice to reduce noise from such intermittent issues and also get
rid of such bugs in the future.
My gut feeling is that we just significantly reduced a probability of
this failure in something
like an order of magnitude but it will still happens once in a month or
a half of yea
Hi Harold,
Sorry Mandy's comment raised a couple of issues ...
On 29/05/2020 7:12 am, Mandy Chung wrote:
Hi Harold,
On 5/27/20 1:35 PM, Harold Seigel wrote:
Incremental webrev:
http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.incr.2/
full webrev:
http://cr.openjdk.java.net/~hsei
Hi Chris,
On 05/28/2020 15:22, Chris Plummer wrote:
Hi Alex,
Overall looks good to me. I'll be real happy if I never see
"WaitForEvent Failed!" again in our CI runs. Just one nit:
I hope so.
402 // see JDK-8204994: sometimes WaitForEvent fails with E_ACCESSDENIED,
403 // but succeeded
Hi Serguei,
With my testing 2nd call always succeeded, but I was able to reproduce
the case only 3 times with my test runs.
I can implement the loop, but number of retries is anyway an arbitrary
value.
--alex
On 05/28/2020 15:44, serguei.spit...@oracle.com wrote:
Hi Alex,
It looks good in
Thanks for confirming it.
Mandy
On 5/28/20 3:31 PM, Harold Seigel wrote:
Hi Mandy,
The entries in the PermittedSubclasses attribute are constant pool
ConstantClass_info entries. These names get validated by the VM in
this code in ClassFileParser::parse_constant_pool():
for (index =
Hi Coleen,
The updated webrev version is:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/jvmti-redef.3/
It has your suggestions addressed:
- remove log_is_enabled conditions
- move ResourceMark's out of loops
Thanks,
Hi Chris and David,
Thank you for reviewing this change.
--Best regards,
Daniil
On 5/26/20, 4:33 PM, "Chris Plummer" wrote:
Hi Daniil,
Looks good.
thanks,
Chris
On 5/26/20 10:46 AM, Daniil Titov wrote:
> Hi Chris and David,
>
> Please review a new version o
Hi Alex,
It looks good in general.
+static HRESULT WaitForEvent(IDebugControl *ptrIDebugControl) {
+ // see JDK-8204994: sometimes WaitForEvent fails with E_ACCESSDENIED,
+ // but succeeded on 2nd call.
+ HRESULT hr = ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAUL
Hi Mandy,
The entries in the PermittedSubclasses attribute are constant pool
ConstantClass_info entries. These names get validated by the VM in this
code in ClassFileParser::parse_constant_pool():
for (index = 1; index < length; index++) {
const jbyte tag = cp->tag_at(index).va
Hi Alex,
Overall looks good to me. I'll be real happy if I never see
"WaitForEvent Failed!" again in our CI runs. Just one nit:
402 // see JDK-8204994: sometimes WaitForEvent fails with E_ACCESSDENIED,
403 // but succeeded on 2nd call.
I think "succeeds" would be better than "succeeded".
Hi Coleen,
Thank you a lot for reviewing this!
On 5/28/20 12:48, coleen.phillim...@oracle.com wrote:
Hi
Serguei,
Sorry for the delay reviewing this again.
On 5/18/20 3:30 AM, serguei.spit...@oracle.com wrote:
Hi Harold,
On 5/27/20 1:35 PM, Harold Seigel wrote:
Incremental webrev:
http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.incr.2/
full webrev:
http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.2/webrev/
Class.java
4406 ReflectionData rd = reflectionData();
4407 ClassDesc
Hi Serguei,
Sorry for the delay reviewing this again.
On 5/18/20 3:30 AM, serguei.spit...@oracle.com wrote:
Hi Coleen and potential reviewers,
Now, the webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/jvmti-redef.2/
has a complete fix for all three failure modes related to the
guara
Sure, you could just have cache_jvmti_state() return a boolean to bail
out immediately for is_old.
dl
On 5/28/20 7:23 AM, serguei.spit...@oracle.com wrote:
Hi Dean,
Thank you for looking at this!
Okay. Let me check what cab be done in this direction.
There is no point to cache is_old. The com
Vladimir Ivanov is on break currently.
It looks good to me.
Thanks,
Vladimir K
On 5/26/20 7:31 AM, Reingruber, Richard wrote:
Hi Vladimir,
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/
Not an expert in JVMTI code base, so can't comment on the actual changes.
From
Hi Dean,
Thank you for looking at this!
Okay. Let me check what cab be done in this direction.
There is no point to cache is_old. The compilation has to bail out
if it is discovered to be true.
Thanks,
Serguei
On 5/28/
This seems OK as long as the memory barriers in the thread state
transitions prevent the C++ compiler from doing something like reading
is_old before reading redefinition_count. I would feel better if both
JVMCI and C1/C2 cached is_old and redefinition_count at the same time
(making sure to be
18 matches
Mail list logo