Dmitry,
Instead of hardcoding the field offsets, you can use InstanceKlass::find_field
and fieldDescriptor::offset to find the offset at runtime.
Thanks,
/Staffan
On 31 maj 2015, at 13:43, Dmitry Samersoff dmitry.samers...@oracle.com
wrote:
Everyone,
Please take a look at new version
On 06/01/2015 10:32 AM, Ulf Zibis wrote:
Hi,
Am 31.05.2015 um 18:03 schrieb Ivan Gerasimov:
On 31.05.2015 18:54, Ivan Gerasimov wrote:
I fixed the code and added the case to the regression test in the
new webrev.
Which is right here:
Hi Aleksey,
While it's true that the denser format will require fewer cachelines, my
experience is that most strings are smaller than a single cacheline worth
of storage, maybe two lines in some cases; there's just a ton of them in
the heap. So the heap footprint should be substantially reduced,
On 05/18/2015 05:35 PM, Vitaly Davidovich wrote:
This part is a bit unclear for the proposed changes. While it's true that
single byte encoding will be denser than two byte, most string ops end up
walking the backing store linearly; prefetch (either implicit h/w or
software-assisted) could
Hi Moh,
On 06/01/2015 04:42 AM, Rezaei, Mohammad A. wrote:
The problems start with the ReferenceQueue object and the heavy
synchronization in it. Consider structures like j.u.WeakHashMap that
need to expunge entries. If such structures are made somewhat
concurrent, the lock in
(getting back to this)
Hi Jeremy,
On 05/16/2015 03:34 AM, Jeremy Manson wrote:
So, I'm pretty dubious, mostly because of the risks mentioned in the JEP.
If you need a flag-check and two code paths for every String method, that's
going to make the String class more slow and bloated, and make
Hi Ivan,
nitpicking mode=on/
Le 31 mai 2015 17:54:35 CEST, Ivan Gerasimov ivan.gerasi...@oracle.com a
écrit :
Hi Remi!
On 31.05.2015 11:43, Remi Forax wrote:
I agree with the others the code is more readable.
There is a slightly difference between the current behavior and the
behavior of
Hi,
Am 31.05.2015 um 18:03 schrieb Ivan Gerasimov:
On 31.05.2015 18:54, Ivan Gerasimov wrote:
I fixed the code and added the case to the regression test in the new webrev.
Which is right here:
http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/
Shoudn't the user be informed via
On May 31, 2015, at 6:03 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
Which is right here:
http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/
Much better.
For the test can you use RandomFactory recently added to the test library?
Paul.
Hi Vladmir
It seems we have only this bug that manifests the problem. As I
understand, this is a product issue, not test.
-Konstantin
On 29.05.2015 14:49, Vladimir Ivanov wrote:
What do you mean by ignore code cache overflow? Do you mean I should fix
the test to ignore these errors or
I read the code in the prototype and I liked what I saw (even excited!), which
is the reason I spoke up.
On the API side, I was mulling over what the addition of bulk methods and even
just a size() method could do to help and it struck me: the JDK has come a long
way since 1.0 and there are
Please review test library changes to remove javac lint warnings.
And 1 test that incorrectly used try-with-resources.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-testlint-8081565/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8081565
Thanks, Roger
On 06/01/2015 03:54 PM, Vitaly Davidovich wrote:
While it's true that the denser format will require fewer cachelines, my
experience is that most strings are smaller than a single cacheline
worth of storage, maybe two lines in some cases; there's just a ton of
them in the heap. So the heap
My calculation doesn't assume cacheline granularity; I'm looking at
strictly the strings. What's allocated next to/around them is completely
arbitrary, circumstantial, uncontrollable to a large extent, and often not
repeatable. If you're claiming that some second or even third order
locality
Please review this testbug fix to correctly check the reported command name.
On Windows the command filename may differ only by case
and should be checked to see if they are the same file, not just the
same string.
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-infotest-8081566/
Issue:
Hi Roger,
The changes all seem reasonable
Best
Lance
On Jun 1, 2015, at 9:57 AM, Roger Riggs roger.ri...@oracle.com wrote:
Please review this testbug fix to correctly check the reported command name.
On Windows the command filename may differ only by case
and should be checked to see if they
Hi Roger,
These changes also look fine
Best
Lance
On Jun 1, 2015, at 9:32 AM, Roger Riggs roger.ri...@oracle.com wrote:
Please review test library changes to remove javac lint warnings.
And 1 test that incorrectly used try-with-resources.
Webrev:
On 01/06/2015 14:57, Roger Riggs wrote:
Please review this testbug fix to correctly check the reported command
name.
On Windows the command filename may differ only by case
and should be checked to see if they are the same file, not just the
same string.
File path comparison is case
On 01.06.2015 11:33, Paul Sandoz wrote:
On May 31, 2015, at 6:03 PM, Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
Which is right here:
http://cr.openjdk.java.net/~igerasim/8058779/05/webrev/
Much better.
For the test can you use RandomFactory recently added to the test library?
Sure.
Ivan,
The code looks fine for me.
Just wonder what's the motivation of using the newStringUnsafe() in the test
case. Simply
to save the char[] copy to speed up the test? I don't think we really care
about it here,
right?
-Sherman
On 06/01/2015 11:53 AM, Ivan Gerasimov wrote:
On
Please review a change to report the user/owner in ProcessHandle.info to
have the same form for the owner identification as provided by
java.nio.Files.
On Windows it includes the domain with the user name.
The test is updated to remove a dependency on the OS command whoami
and instead compare
Hello,
Please review these changes to regularize the jaxp regression testing
infrastructure with the JDK tiered testing policy. [1]
JDK-8075551: Add tiered testing definitions to the jaxp repo
http://cr.openjdk.java.net/~darcy/8075551.0/
In brief, testing tiers are defined (with an
On 6/1/2015 3:16 PM, joe darcy wrote:
Hello,
Please review these changes to regularize the jaxp regression testing
infrastructure with the JDK tiered testing policy. [1]
JDK-8075551: Add tiered testing definitions to the jaxp repo
http://cr.openjdk.java.net/~darcy/8075551.0/
In
On 6/1/2015 6:15 PM, huizhe wang wrote:
On 6/1/2015 3:16 PM, joe darcy wrote:
Hello,
Please review these changes to regularize the jaxp regression testing
infrastructure with the JDK tiered testing policy. [1]
JDK-8075551: Add tiered testing definitions to the jaxp repo
24 matches
Mail list logo
