Daniil and David,
Just wanted to let you know that I'm reviewing this.
On 1/20/19 21:18, David Holmes wrote:
Thanks for the update Daniil. I still remain concerned about the
robustness of the command-line parsing - this seems like a feature
that needs its own set of tests.
I guess, the mai
Hi David, Paul,
I have uploaded the refined webrev at
http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/
And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131
May I ask your help to review?
Thanks!
BRs,
Lin
From: D
Yes, David suggested the same.
Your emails crossed.
Thanks,
Serguei
On 1/30/19 21:22, Igor Ignatyev wrote:
from my
point of view, having the following code at the end
of JvmtiManageCapabilities::init_onload_capabilities is much c
On 1/30/19 21:24, David Holmes wrote:
On 31/01/2019 3:18 pm, dean.l...@oracle.com wrote:
On 1/30/19 8:59 PM, serguei.spit...@oracle.com wrote:
So, the fix needs to be more like this:
+ // Workaround for 8195635:
+ // disable pop_frame and force_early_return capabilities with Graal
+ #if INCLUDE
On 31/01/2019 3:18 pm, dean.l...@oracle.com wrote:
On 1/30/19 8:59 PM, serguei.spit...@oracle.com wrote:
So, the fix needs to be more like this:
+ // Workaround for 8195635:
+ // disable pop_frame and force_early_return capabilities with Graal
+ #if INCLUDE_JVMCI
+ if (!(EnableJVMCI && UseJVMCIC
from my point of view, having the following code at the end of
JvmtiManageCapabilities::init_onload_capabilities is much clear and easier to
understand:
> // Workaround for 8195635: disable pop_frame and force_early_return
> capabilities
> #if INCLUDE_JVMCI
> if (UseJVMCICompiler) {
> jc.
On 1/30/19 8:59 PM, serguei.spit...@oracle.com wrote:
So, the fix needs to be more like this:
+ // Workaround for 8195635:
+ // disable pop_frame and force_early_return capabilities with Graal
+ #if INCLUDE_JVMCI
+ if (!(EnableJVMCI && UseJVMCICompiler)) {
jc.can_pop_frame = 1;
jc.can_for
On 1/30/19 20:46,
serguei.spit...@oracle.com wrote:
Hi
Alex,
Vladimir I. also mentioned the same as Igor that it is safe to use
UseJVMCICompiler under "ifdef INCLUDE_JVMCI".
One example from the runtime/thread.cpp:
Hi Alex,
Vladimir I. also mentioned the same as Igor.
One example from the runtime/thread.cpp:
#if INCLUDE_JVMCI
bool force_JVMCI_intialization = false;
if (EnableJVMCI) {
// Initialize JVMCI eagerly when it is explicitly requested.
// Or when JVMCIPrintProperties is enabled.
//
Thank you, David!
- Jini.
On 1/31/2019 7:45 AM, David Holmes wrote:
Hi Jini,
This looks reasonable to me.
Thanks,
David
On 30/01/2019 9:59 pm, Jini George wrote:
Requesting reviews for:
BugID: https://bugs.openjdk.java.net/browse/JDK-8217473
Webrev:http://cr.openjdk.java.net/~jgeorge/82174
Hi Jini,
This looks reasonable to me.
Thanks,
David
On 30/01/2019 9:59 pm, Jini George wrote:
Requesting reviews for:
BugID: https://bugs.openjdk.java.net/browse/JDK-8217473
Webrev:http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/index.html
The patch includes changes to use SkippedExcep
Hi Alex,
UseJVMCICompiler is declared only if INCLUDE_JVMCI is defined, so your current
patch will break builds where it's undefined. the rest (esp. problem list ;) )
looks good to me.
adding hotspot-compiler alias.
Thanks,
-- Igor
> On Jan 30, 2019, at 5:27 PM, Alex Menkov wrote:
>
> Hi al
Hi all,
Please review a fix for tck-red bug:
https://bugs.openjdk.java.net/browse/JDK-8218025
webrev:
http://cr.openjdk.java.net/~amenkov/tck_red_disable_caps/webrev/
ForceEarlyReturn and PopFrame JCK tests intermittently fail with Graal.
Real fix for the issue is too risky for jdk12, so we have
On 31/01/2019 10:41 am, Hohensee, Paul wrote:
Also, I suspect that this change needs a CSR, since we're adding functionality
to jmap's histo switch. Opinions?
Yes. Changes to command-line flags need a CSR.
Thanks,
David
Thanks,
Paul
On 1/30/19, 9:33 AM, "serviceability-dev on behalf of H
Also, I suspect that this change needs a CSR, since we're adding functionality
to jmap's histo switch. Opinions?
Thanks,
Paul
On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul"
wrote:
A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to
heapHisto() by a
Hi Gary,
It looks good to me.
Nice discovery!
Thanks,
Serguei
On 1/30/19 15:03, gary.ad...@oracle.com wrote:
Second reviewer or is it trivial enough for one?
On 1/30/19 1:57 PM, Chris Plummer wrote:
This looks good.
thanks,
Chris
On 1/30/19 8:24 AM, Gary Adams wrote:
Following the trail
Second reviewer or is it trivial enough for one?
On 1/30/19 1:57 PM, Chris Plummer wrote:
This looks good.
thanks,
Chris
On 1/30/19 8:24 AM, Gary Adams wrote:
Following the trail from debugLoop_run, at the bottom of the loop
there is a path through debugInit_reset that involves eventHandler_
This looks good.
thanks,
Chris
On 1/30/19 8:24 AM, Gary Adams wrote:
Following the trail from debugLoop_run, at the bottom of the loop
there is a path through debugInit_reset that involves eventHandler_reset
and eventually eventHelper_reset. This seems like a better place to
clear the flag bac
A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by
a space.
vm.heapHisto("", "-live")
Also, the header comment line for getInstanceCountFromHeapHisto() should be
changed to
* 'vm.heapHisto("", "-live")' will request a full GC
In attachListener.cpp, the line
Following the trail from debugLoop_run, at the bottom of the loop
there is a path through debugInit_reset that involves eventHandler_reset
and eventually eventHelper_reset. This seems like a better place to
clear the flag back to original state.
Revised webrev: http://cr.openjdk.java.net/~gadam
Requesting reviews for:
BugID: https://bugs.openjdk.java.net/browse/JDK-8217473
Webrev:http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/index.html
The patch includes changes to use SkippedException to skip the tests
when canPtraceAttachLinux() in Platform.java returns false.
Thanks,
Jini
On 1/30/19 10:00 AM, David Griffiths wrote:
> I'm not sure this works though for the frame at the top of the stack.
> The pushing of the registers that you mention appears to take place in
> the updateRegisterMap method which is called when getting the sender.
> At the top of the stack the register
I'm not sure this works though for the frame at the top of the stack.
The pushing of the registers that you mention appears to take place in
the updateRegisterMap method which is called when getting the sender.
At the top of the stack the register will be live and not saved
anywhere?
Whatever, I'm
Dear All,
This issue mentioned is that test case
"java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev.
I have identified the root cause of the issue. it is caused by 2 problems.
1. The path processing in heap_inspection() at attachListener.cpp.
The p
24 matches
Mail list logo
