Hi Erik,
On 31/10/2014 9:41 AM, Eric McCorkle wrote:
Hello,
Please review this patch which adds tests to the JDK test suite for two
reflection bugs that require hotspot changes (JDK-8058322 and JDK-8058313)
The webrev is here:
http://cr.openjdk.java.net/~emc/8062556/
I second Brian's comment
+1. Nice to improve test coverage.
-Joe
On 10/30/2014 10:38 AM, Lance Andersen wrote:
Hi all,
Looking for a reviewer for the javax/sql/rowset/spi tests
The webrev can be found at http://cr.openjdk.java.net/~lancea/8062558/webrev.00/
Best
Lance
Lance Andersen| Principal Member of Technic
I realize you are just adding new bad class files to an existing test,
so you're just copying the idiom in the test, but it would be 1000 times
more helpful if the comments included a javap or similar listing or even
a description of what (bad) class this byte[] array purports to be.
Otherwise,
Hello,
Please review this patch which adds tests to the JDK test suite for two
reflection bugs that require hotspot changes (JDK-8058322 and JDK-8058313)
The webrev is here:
http://cr.openjdk.java.net/~emc/8062556/
On 10/30/14 2:21 AM, Chris Hegarty wrote:
On 30 Oct 2014, at 07:31, David Holmes wrote:
On 30/10/2014 4:00 PM, Stanimir Simeonoff wrote:
It could be defense vs Thread.currentThread().run() in finalizer that
would cause calling run() of Thread.target. I am not sure if that would
cause invocatio
Hi Frederic,
On Thu, Oct 30, 2014 at 10:54 AM, frederic parain
wrote:
> My bad. I missed the FD_CLOEXEC flag added by os::open()
> when I replaced JVM_Open with open in zip native code.
>
> However, I still think that removing those interfaces
> was a good move. But I understand that the change i
On Oct 30, 11:26am, marti...@google.com (Martin Buchholz) wrote:
-- Subject: Re: Losing features of JVM_Open, e.g. CLOEXEC
| On Thu, Oct 30, 2014 at 10:52 AM, Mario Torre
| wrote:
| > Indeed, but /proc/$PID/fd can perhaps be useful here? Not sure if this
| > can make a reasonable test though.
|
On Thu, Oct 30, 2014 at 10:52 AM, Mario Torre
wrote:
> Indeed, but /proc/$PID/fd can perhaps be useful here? Not sure if this
> can make a reasonable test though.
Mario, I'm not sure what you mean.
Even if we can find and inspect each fd, and even if we knew the
stacktrace of where every fd was
Hi Peter!
Thanks for all your hard work.
Your patch is hard to digest, but some initial comments anyways:
---
I'm surprised you got this much performance gain loading rt.jar methods.
It looks like you are creating a more sophisticated data structure
with more garbage, which won't show up as muc
My bad. I missed the FD_CLOEXEC flag added by os::open()
when I replaced JVM_Open with open in zip native code.
However, I still think that removing those interfaces
was a good move. But I understand that the change it
introduces with zip file descriptors is an issue.
Reverting the changeset to
Indeed, but /proc/$PID/fd can perhaps be useful here? Not sure if this
can make a reasonable test though.
Cheers,
Mario
2014-10-30 18:30 GMT+01:00 Martin Buchholz :
> On Thu, Oct 30, 2014 at 3:24 AM, Mario Torre
> wrote:
>> I've been thinking perhaps one can use fcntl to check what flags are
>>
Hi all,
Looking for a reviewer for the javax/sql/rowset/spi tests
The webrev can be found at http://cr.openjdk.java.net/~lancea/8062558/webrev.00/
Best
Lance
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
On Thu, Oct 30, 2014 at 3:24 AM, Mario Torre
wrote:
> I've been thinking perhaps one can use fcntl to check what flags are
> passed given we can retrieve all the file descriptors that have been
> opened?
It's possible to find all the open file descriptors (e.g. using
/proc/self/fd), but they may
On Thu, Oct 30, 2014 at 6:08 AM, Alan Bateman wrote:
> The change in behavior from JVM_Open ito open was missed but there is a long
> way to go in JDK 9 so lots of time to fix the issue (if there is an issue).
The changes to zip file file descriptors is just the one most visible to me.
> As was
Here's the state of the world:
- the Unix designers made a design mistake that file descriptors are
inherited by subprocesses by default.
- all library code (almost all the code in the universe, including the
JDK) needs to coexist with foreign code that might fork+exec at any
time
- to ensure that
Hi,
Here's a patch:
http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods/webrev.04/
for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8061950
For those following the thread "Loading classes with many methods is
very expensive", this is a 4th iteration of this patch.
Thanks Ioi - looks good.
thanks,
Karen
On Oct 30, 2014, at 1:26 AM, Ioi Lam wrote:
> OK, here's the latest version. I removed the synchronization but kept the
> resolveClass just for completeness, even if it currently does nothing.
>
>class Launcher$AppClassLoader {
>
>publ
Thanks Joe, Alan,
On 10/30/2014 9:10 AM, Alan Bateman wrote:
On 30/10/2014 02:28, roger riggs wrote:
Please review a correction to address a doclint warning in
HijrahChronology.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-doclint-8062513/
Issue:
8062513: doclint warnings in Hijr
On 30/10/2014 02:28, roger riggs wrote:
Please review a correction to address a doclint warning in
HijrahChronology.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-doclint-8062513/
Issue:
8062513: doclint warnings in HijrahChronology
This looks to me, you might to just split the line
On 29/10/2014 20:12, Martin Buchholz wrote:
Hi guys,
In your change
805: Cleanup of old and unused VM interfaces
you have made changes like this:
-zfd = JVM_Open(path, flag, 0);
+zfd = open(path, flag, 0);
throwing away use of old shared infrastructure and replaci
I've been thinking perhaps one can use fcntl to check what flags are
passed given we can retrieve all the file descriptors that have been
opened?
Using raw open complicates the matter though.
Cheers,
Mario
2014-10-30 11:16 GMT+01:00 Mario Torre :
> This is exactly what I was about to reply. One
This is exactly what I was about to reply. One can only spot those
things if there is a standardised API, and even in this case it's not
at all easy. That doesn't stop from trying :) but removing the API was
likely a mistake, which would not be a terrible one because of what
David points, except th
Sorry, I apologize. I'll start a new thread on core-libs only.
Peter
On 10/30/2014 10:47 AM, Aleksey Shipilev wrote:
Guys, can you please start a new RFR thread for Peter's change? You have
a bug ID now, and the discussion should be searchable by bug ID.
Also, you are spamming two aliases (cor
Guys, can you please start a new RFR thread for Peter's change? You have
a bug ID now, and the discussion should be searchable by bug ID.
Also, you are spamming two aliases (corelibs + hotspot-runtime) instead
of one ;)
-Aleksey.
On 10/30/2014 12:43 PM, Peter Levart wrote:
> On 10/30/2014 10:29
On 30/10/2014 6:46 PM, Alan Bateman wrote:
On 29/10/2014 21:15, Mario Torre wrote:
+1
We should have spotted it in the review though.
We should but the ultimate rat catcher should be the tests, it's
possible that we have a hole there.
Not sure how the presence or absence of CLOEXEC would
On 10/30/2014 10:29 AM, Peter Levart wrote:
I might get away with excluding seq from hashCode computation and only
use it in equals(). This way Key(s) could be modified in-place
(hashCode would not change, entry would stay in same bucket), it would
just become equal to some other Key. Modificat
Hi Stanimir,
On 10/30/2014 12:00 AM, Stanimir Simeonoff wrote:
Hi Peter,
The removal of value wrapper is a clever approach to reduce the new
instances created although it feels very unnatural (at least to me).
Number of objects created is practically the same. Previous approach
used same Met
On 30 Oct 2014, at 07:31, David Holmes wrote:
> On 30/10/2014 4:00 PM, Stanimir Simeonoff wrote:
>>
>>Aside, I noticed in this code:
>>
>> 146 forkSecondaryFinalizer(new Runnable() {
>> 147 private volatile boolean running;
>> 148 public void r
On 29/10/2014 21:15, Mario Torre wrote:
+1
We should have spotted it in the review though.
We should but the ultimate rat catcher should be the tests, it's
possible that we have a hole there.
On 30/10/2014 4:00 PM, Stanimir Simeonoff wrote:
Aside, I noticed in this code:
146 forkSecondaryFinalizer(new Runnable() {
147 private volatile boolean running;
148 public void run() {
149 if (running)
150
30 matches
Mail list logo
