On 2014-11-02, at 10:49 PM, David Holmes david.hol...@oracle.com wrote:
The change is to load the volatile size for the loop bound; this stops the
stores
in the loop from moving earlier, right?
Treating volatile accesses like memory barriers is playing a bit
fast-and-loose with the
I have been having issues with webrev, which I reported earlier. Webrev
reports a syntax error when I try to use it, and curiously, it fails to
produce top-level files in this case (and this case only, as evidenced
by my other webrevs).
Unfortunately, there's nothing I can do about the missing
On 11/03/2014 01:49 PM, David Chase wrote:
On 2014-11-02, at 10:49 PM, David Holmes david.hol...@oracle.com wrote:
The change is to load the volatile size for the loop bound; this stops the
stores
in the loop from moving earlier, right?
Treating volatile accesses like memory barriers is
Gently reminder
29.10.2014 17:25, Konstantin Shefov пишет:
Please, review a test bug fix.
http://cr.openjdk.java.net/~kshefov/8059070/webrev.01/
-Konstantin
On 27.10.2014 13:16, Konstantin Shefov wrote:
Kindly reminder
On 23.10.2014 19:04, Paul Sandoz wrote:
On Oct 23, 2014, at 1:25 PM,
My main concern is that the compiler is inhibited from any peculiar code
motion; I assume that taking a safe point has a bit of barrier built into it
anyway, especially given that the worry case is safepoint + JVMTI.
Given the worry, what’s the best way to spell “barrier” here?
I could
On 11/03/2014 05:16 PM, Peter Levart wrote:
On 11/03/2014 01:49 PM, David Chase wrote:
On 2014-11-02, at 10:49 PM, David Holmes david.hol...@oracle.com
wrote:
The change is to load the volatile size for the loop bound; this
stops the stores
in the loop from moving earlier, right?
Treating
On 2014-11-03, at 11:42 AM, Peter Levart peter.lev...@gmail.com wrote:
You're worried that writes moving array elements up for one slot would
bubble up before write of size = size+1, right? If that happens, VM could
skip an existing (last) element and not update it.
It seems that
Hi David,
I was thinking about the fact that java.lang.invoke code is leaking into
java.lang.Class. Perhaps, If you don't mind rewriting the code, a better
code structure would be, if j.l.Class changes only consisted of adding a
simple:
+ // A reference to canonicalizing cache of
On 2014-11-03, at 3:09 PM, Peter Levart peter.lev...@gmail.com wrote:
Hi David,
I was thinking about the fact that java.lang.invoke code is leaking into
java.lang.Class. Perhaps, If you don't mind rewriting the code, a better code
structure would be, if j.l.Class changes only consisted
Hi,
The order of the Character event for a built-in entity reference was
wrong after the integration of StAX in JDK 6. The error was introduced
when all Character event was moved to the scanDocument method. The
Character event in handleCharacter method was then commented out to
avoid
On Nov 3, 2014, at 12:41 PM, David Chase david.r.ch...@oracle.com wrote:
On 2014-11-03, at 3:09 PM, Peter Levart peter.lev...@gmail.com wrote:
Hi David,
I was thinking about the fact that java.lang.invoke code is leaking into
java.lang.Class. Perhaps, If you don't mind rewriting the
This issue is an 8u40 issue, so it needs to be reviewed ASAP in order to
backport it in time.
On 10/31/14 12:15, Eric McCorkle wrote:
Hello,
Please review this patch which fixes issues that arise with
getGenericParameterTypes() and getAnnotatedParameterTypes() when there
are generic
Hi Tristan,
Looks good overall. Once again, it's great to see that you've made the
tests a lot cleaner, getting rid of the old report system and etc.
The only issue I see is with movies.xml. If I use patch to apply your
patch to my workspace, I get no movies.xml that in turn causes
13 matches
Mail list logo
