You need to wait when Mark (OpenJDK Lead) move it to Candidate (or
other) state:
http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
Vladimir
On 9/29/16 9:55 AM, Volker Simonis wrote:
Hi Vladimir,
thanks a lot for reviewing and endorsing the JEP.
I've linked all the relevant issues to the JE
+1.
Kumar
On 29/09/2016 16:25, Erik Joelsson wrote:
Volker's comment above was directed at the suggestion of taking the
problematic AIX specific code out of the OpenJDK repositories and create
a separate library with a separate lifecycle somewhere else that OpenJDK
for AIX would then need to
On 29/09/2016 16:25, Erik Joelsson wrote:
Volker's comment above was directed at the suggestion of taking the
problematic AIX specific code out of the OpenJDK repositories and create
a separate library with a separate lifecycle somewhere else that OpenJDK
for AIX would then need to depend on. Vo
On Thu, Sep 29, 2016 at 5:25 PM, Erik Joelsson wrote:
>
>
> On 2016-09-29 16:54, Alan Burlison wrote:
>>
>> On 29/09/2016 08:03, Volker Simonis wrote:
>>
>>> Sorry, but that doesn't sound like a solution to me at all. I think we
>>> should keep the OpenJDK sources self-contained. I don't want to d
Hi Vladimir,
thanks a lot for reviewing and endorsing the JEP.
I've linked all the relevant issues to the JEP (they all have a link
to a webrev) and change the state to "Submitted".
There's just one more small shared change we need for the port for
which we haven't opened a bug now because we a
A lot of ideas have been thrown around so solve the problem of duplicated code
in this situation. And there are other cases that are nearly identical so we
need a general solution. The fact is this code should be moved to a common
location. Since OpenJDK depends on Posix, Windows API and a few o
Erik:
On 09/29/16 00:21, Magnus Ihse Bursie wrote:
On 2016-09-28 17:42, Erik Joelsson wrote:
When linking C++ on Linux, we currently have a clunky construct to
enforce static linking of libstdc++ and libgcc which looks like this:
-Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic
To make it work, we a
On 2016-09-29 16:54, Alan Burlison wrote:
On 29/09/2016 08:03, Volker Simonis wrote:
Sorry, but that doesn't sound like a solution to me at all. I think we
should keep the OpenJDK sources self-contained. I don't want to depend
on yet another non-standard, third party library which doesn't eve
On 29/09/2016 08:03, Volker Simonis wrote:
Sorry, but that doesn't sound like a solution to me at all. I think we
should keep the OpenJDK sources self-contained. I don't want to depend
on yet another non-standard, third party library which doesn't even
exist now.
Unless I'm completely misunder
On 2016-09-29, David Holmes wrote:
>
>
> On 29/09/2016 5:52 PM, Erik Helin wrote:
> >On 2016-09-29, David Holmes wrote:
> >>Hi Erik,
> >
> >Hi David, thanks for reviewing!
> >
> >>On 29/09/2016 1:01 AM, Erik Helin wrote:
> >>>Hi all,
> >>>
> >>>this patch adds a new GC stress test called GCBasher
Hi,
On Wed, 2016-09-28 at 17:01 +0200, Erik Helin wrote:
> Hi all,
>
> this patch adds a new GC stress test called GCBasher. GCBasher builds
> up
> large (well, for some definiton of large) object graphs by figuring
> out
> the relations between classes in the JDK. The test usually stresses
> the
Hello,
From my point of view, now that I better understand what aix/porting
actually was/is, I would say go for it. Put something together the way
you would like it. I doubt there will ever be much code needed in this
new entity so it can go in the top level repo without problems. There is
al
On 29/09/2016 5:52 PM, Erik Helin wrote:
On 2016-09-29, David Holmes wrote:
Hi Erik,
Hi David, thanks for reviewing!
On 29/09/2016 1:01 AM, Erik Helin wrote:
Hi all,
this patch adds a new GC stress test called GCBasher. GCBasher builds up
large (well, for some definiton of large) object
On 2016-09-29, David Holmes wrote:
> Hi Erik,
Hi David, thanks for reviewing!
> On 29/09/2016 1:01 AM, Erik Helin wrote:
> >Hi all,
> >
> >this patch adds a new GC stress test called GCBasher. GCBasher builds up
> >large (well, for some definiton of large) object graphs by figuring out
> >the rel
On 2016-09-29 06:14, David Holmes wrote:
Hi Erik,
On 29/09/2016 1:01 AM, Erik Helin wrote:
This seems wrong:
443
${my.make.rule.test.targets.hotspot.reg.group:GROUP=hotspot_fast_gc_gcbasher},
\
444
${my.make.rule.test.targets.hotspot.reg.group:GROUP=hotspot_fast_runtime},
On 2016-09-28 17:42, Erik Joelsson wrote:
When linking C++ on Linux, we currently have a clunky construct to
enforce static linking of libstdc++ and libgcc which looks like this:
-Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic
To make it work, we also change the linker to "gcc" instead of "g++".
Th
On Wed, Sep 28, 2016 at 8:54 PM, Chris Bensen wrote:
>
> On Sep 28, 2016, at 11:50 AM, Thomas Stüfe wrote:
>
>
>
> On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz
> wrote:
>>
>> On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis
>> wrote:
>>
>> >
>> > I don't think this can be easily done with th
17 matches
Mail list logo
