Thank you very much, Chris, for taking a look.
The bytecodes table initialization in SA's Bytecodes.java mimics the
bytecodes table initialization in hotspot's Bytecodes::initialize() from
bytecodes.cpp. In bytecodes.cpp, we have the initialization of the
_nofast* bytecodes thus:
def(_nofast_
I'm not too sure how that field ends up getting used. I'd say what's
likely in this case is that it's wrong but doesn't matter. Hopefully
someone with a better understanding of the use of this field will chime in.
Chris
On 5/11/18 12:29 AM, Jini George wrote:
Thank you very much, Chris, for t
Thank you, David. Could I get another pair of eyes to take a look at:
http://cr.openjdk.java.net/~jgeorge/8195613/webrev.02/index.html
Thanks,
Jini.
On 5/11/2018 11:58 AM, David Holmes wrote:
Forgot to add - no need to see an updated webrev.
Thanks,
David
On 11/05/2018 4:22 PM, David Holmes
Looks good to me,
Misha
On 5/9/18, 5:14 PM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8202392/webrev.00/index.html
1396 lines changed: 1396 ins; 0 del; 0 mod;
Hi all,
could you please review his patch which open sources heapdump tests from
so-called VM testbase? as it's ob
I think all code that looks at the top of stack (e.g., users of
BytecodeStream) operate with the original bytecode (_aload_0), not the
quicken one (_fast_aload_0 or _nofast_aload_0), so this bug is never
discovered. But I think this is still a bug and should be fixed.
I filed https://bugs.open
Thanks Ioi.
Jini, you can count me as a reviewer for your changes.
thanks,
Chris
On 5/11/18 9:34 AM, Ioi Lam wrote:
I think all code that looks at the top of stack (e.g., users of
BytecodeStream) operate with the original bytecode (_aload_0), not the
quicken one (_fast_aload_0 or _nofast_alo
Actually I did notice that and had a new webrev ready to go out and en
email drafted, but then noticed the solaris-sparc timeout when I tested
again.
Chris
On 5/10/18 9:50 PM, David Holmes wrote:
I was going to say that you also need to remove:
29 # @requires os.family != "windows"
30 #
Hi Jini,
It looks good to me.
A minor comment on the ClhsdbLongConstant.java.frames.html:
Could you add a comment with an example of the expected longConstantOutput?
I do not need another webrev if you add it.
Thanks,
Sergu
Hi Jini,
Why do you have the following:
98 if (arch.equals("amd64") || arch.equals("i386") ||
arch.equals("x86")) {
Is it because VM_Version::CPU_SHA is only expected on these platforms?
If so, is there a reason you didn't choose a long constant that exists
on all platforms?
And
+1
Thanks,
Serguei
On 5/11/18 06:52, Mikhailo Seledtsov wrote:
Looks good to me,
Misha
On 5/9/18, 5:14 PM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8202392/webrev.00/index.html
1396 lines changed: 1396 ins; 0 del; 0 mod;
Hi all,
could you please review his patch which o
Thanks, Ioi.
- Jini.
On 5/11/2018 10:04 PM, Ioi Lam wrote:
I think all code that looks at the top of stack (e.g., users of
BytecodeStream) operate with the original bytecode (_aload_0), not the
quicken one (_fast_aload_0 or _nofast_aload_0), so this bug is never
discovered. But I think this i
Thanks, Chris.
- Jini.
On 5/11/2018 11:26 PM, Chris Plummer wrote:
Thanks Ioi.
Jini, you can count me as a reviewer for your changes.
thanks,
Chris
On 5/11/18 9:34 AM, Ioi Lam wrote:
I think all code that looks at the top of stack (e.g., users of
BytecodeStream) operate with the original b
12 matches
Mail list logo
