Am Mittwoch, den 27.03.2013, 09:42 -0400 schrieb Omair Majid:
> Hi,
>
> On 03/27/2013 04:55 AM, Erik Joelsson wrote:
> > Work on this was already initiated in this thread:
> >
> > http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-February/003059.html
> >
>
> Whoops. I was not aware of
Am Mittwoch, den 27.03.2013, 09:55 +0100 schrieb Erik Joelsson:
> Work on this was already initiated in this thread:
>
> http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-February/003059.html
>
> Would be good if these efforts could be synchronized.
>
> I like that you define and trans
Yup, fine for me as well! (I'm not a reviewer though... just an opinion)
Roman
Am Mittwoch, den 03.04.2013, 10:28 +0200 schrieb Erik Joelsson:
> This looks good to me. Thanks!
>
> /Erik
>
> On 2013-04-02 23:17, Omair Majid wrote:
> > Hi,
> >
> > Updated patch at:
> > http://cr.openjdk.java.net/
On Tue, 17 Nov 2020 19:11:45 GMT, Aleksey Shipilev wrote:
> Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796)
> improvement that ditched the inline contiguous alloc use from Zero, we can
> now rely on GC interface to hook the GCs properly. Epsilon GC does not
> requ
On Tue, 17 Nov 2020 19:02:03 GMT, Aleksey Shipilev wrote:
> Following the [JDK-8255796](https://bugs.openjdk.java.net/browse/JDK-8255796)
> improvement that ditched the inline contiguous alloc use from Zero, we can
> now rely on GC interface to hook the GCs properly. G1 and Shenandoah are a
>
On Tue, 26 Jan 2021 11:41:52 GMT, Aleksey Shipilev wrote:
> I was following up on performance testing results for some ongoing work, and
> realized that there are `ShenandoahMarkContext::mark_strong` calls from
> `mark_work_loop`. Those callees were supposed to be inlined. I believe it is
> a
On Wed, 10 Nov 2021 09:00:04 GMT, Niklas Radomski wrote:
> Port the Shenandoah garbage collector
> (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
> ppc64le.
Hi Niklas,
thanks for this awesome work!
I can't really comment on the actual PPC code, so this needs to be
On Thu, 11 Nov 2021 14:30:05 GMT, Martin Doerr wrote:
>> src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp line 83:
>>
>>> 81: LIRGenerator* gen = access.gen();
>>> 82:
>>> 83: if (ShenandoahCASBarrier) {
>>
>> I am not sure, but I almost think we should not even end
Hi Roman,
The build changes must be reviewed on build-dev - now cc'd.
Thanks,
David
On 15/10/2017 8:41 AM, Roman Kennke wrote:
The JEP to remove the Shark compiler has received exclusively
positive feedback (JDK-8189173) on zero-dev. So here comes the big
patch to remove it.
What I have d
Hi David,
thanks for reviewing!
One observation in src/hotspot/cpu/zero/sharedRuntime_zero.cpp, these
includes would seem to be impossible:
38 #ifdef COMPILER1
39 #include "c1/c1_Runtime1.hpp"
40 #endif
41 #ifdef COMPILER2
42 #include "opto/runtime.hpp"
43 #endif
no?
I have n
Am 15.10.2017 um 23:25 schrieb David Holmes:
On 16/10/2017 7:01 AM, Roman Kennke wrote:
Hi David,
thanks!
I'm uploading a 2nd revision of the patch that excludes the
generated-configure.sh part, and adds a smallish Zero-related fix.
http://cr.openjdk.java.net/~rkennke/8171853/webr
<http://cr.openjdk.java.net/%7Erkennke/8171853/webrev.03/>
Roman
Just spotted this:
./hotspot/jtreg/compiler/whitebox/CompilerWhiteBoxTest.java: /**
{@code CompLevel::CompLevel_full_optimization} -- C2 or Shark */
David
On 16/10/2017 7:25 AM, David Holmes wrote:
On 16/10/2017 7:01 AM, Roman Kennk
pushed until the JEP has been targeted.
Thanks,
David
On 16/10/2017 8:08 AM, David Holmes wrote:
Looks good.
Thanks,
David
On 16/10/2017 8:00 AM, Roman Kennke wrote:
Ok, I fixed all the comments you mentioned.
Differential (against webrev.01):
http://cr.openjdk.java.net/~rkennke/81718
webrev.04/>
Thanks,
Roman
Hello Roman,
In hotspot.m4, I believe the check on line 328 (pre changes) is still
relevant for just the zero case.
Otherwise build changes look good to me.
/Erik
On 2017-10-16 00:00, Roman Kennke wrote:
Ok, I fixed all the comments you mentioned.
Differential (ag
Hi there,
JDK-8209611 seems to cause many missing-field-initializer warning-errors
like below:
I am using gcc 4.8.5
Compiling libvmdeath001.cpp (for libvmdeath001.so)
In file included from
/home/rkennke/src/openjdk/shenandoah-jdk/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/unit/libHeap.cpp:29:
Not sure this is the correct list. Please redirect as appropriate.
Please review the following proposed change:
There are 3 asserts in unpack.cpp which check only constants, and which
the compiler rejects as 'has no effect' (in fastdebug builds). This
seems to be caused by:
https://bugs.openjdk
Related, I've also filed:
https://bugs.openjdk.java.net/browse/JDK-8211071
and waiting for review here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055666.html
Thanks,
Roman
> Hello, one additonal info , my colleague looking into the compile issues
> after 8211029 f
Ping core-libs?
Roman
Am 25.09.18 um 11:06 schrieb Magnus Ihse Bursie:
>
>> 25 sep. 2018 kl. 10:21 skrev Roman Kennke :
>>
>> Not sure this is the correct list. Please redirect as appropriate.
>
> I believe core-libs is the appropriate place. Cc:d.
>
>
Hi Christoph & Magnus, thanks for reviewing!
Am 27.09.18 um 08:22 schrieb Langer, Christoph:
> Hi Roman,
>
> this looks good to me. +1
>
> Best regards
> Christoph
>
>> -Original Message-
>> From: build-dev On Behalf Of
>> Roman Kennke
>&g
I'd be in favour of disabling by default.
Roman
> Is there any advantage of using precompiled headers on Linux? It's on by
> default and we keep having breakage where someone would forget to add
> #include. The latest instance is JDK-8213148.
>
> I just turn on precompiled headers explicitly in
> On 2018-11-01 11:54, Aleksey Shipilev wrote:
>> On 11/01/2018 11:43 AM, Magnus Ihse Bursie wrote:
>>> But then again, it might just signal that the list of headers
>>> included in the PCH is no longer
>>> optimal. If it used to be the case that ~100 header files were so
>>> interlinked, that c
Hi,
This is the first round of changes for including Shenandoah GC into
mainline.
I divided the review into parts that roughly correspond to the mailing lists
that would normally review it, and I divided it into 'shared' code
changes and
'shenandoah' code changes (actually, mostly additions). The
Thanks for reviewing, Erik!
Roman
> Build changes look ok to me.
>
> /Erik
>
> On 2018-11-26 13:39, Roman Kennke wrote:
>> Hi,
>>
>> This is the first round of changes for including Shenandoah GC into
>> mainline.
>> I divided the review into
On 11/26/18 2:47 PM, Erik Joelsson wrote:
>> Build changes look ok to me.
>>
>> /Erik
>>
>> On 2018-11-26 13:39, Roman Kennke wrote:
>>> Hi,
>>>
>>> This is the first round of changes for including Shenandoah GC into
>>> mainline.
&
Hi Kim,
>> Sections to review (at this point) are the following:
>>
>> *) shared-gc
>> - This is mostly boilerplate that is common to any GC
>> - referenceProcessor.cpp has a little change to make one assert not fail
>> (next to CMS and G1)
>
> Ick. But I don’t have a better suggestion
s and new gc
> specific nodes. This looks intrusive. I hope you clean it up.
>
> Thanks,
> Vladimir
>
> On 11/26/18 2:47 PM, Erik Joelsson wrote:
>> Build changes look ok to me.
>>
>> /Erik
>>
>> On 2018-11-26 13:39, Roman Kennke wrote:
>>> H
Hi Vladimir,
> On 11/27/18 1:37 AM, Roman Kennke wrote:
>> Hi Vladimir,
>>
>>> You need to check if shenandoahgc is disabled first - check
>>> DISABLED_JVM_FEATURES list (see code for jvmci).
>>
>> Why? If Shenandoah is disabled, it will be on
>>> You need to check if shenandoahgc is disabled first - check
>>> DISABLED_JVM_FEATURES list (see code for jvmci).
>>
>> Why? If Shenandoah is disabled, it will be on this list, and therefore
>> not be built (see JvmFeatures.gmk).
>
> Did you test with --with-jvm-variants=-shenandoahgc to make s
Hi Kim,
>> On Nov 27, 2018, at 4:46 AM, Roman Kennke wrote:
>>
>> Hi Kim,
>>
>>>> Sections to review (at this point) are the following:
>>>>
>>>> *) shared-gc
>>>>- This is mostly boilerplate that is common to any GC
>
Hi Kim,
>> On Nov 26, 2018, at 4:39 PM, Roman Kennke wrote:
>> *) shared-gc
>> - This is mostly boilerplate that is common to any GC
>> - referenceProcessor.cpp has a little change to make one assert not fail
>> (next to CMS and G1)
>> - taskque
Hi Per,
> Hi Roman,
>
> On 11/26/18 10:39 PM, Roman Kennke wrote:
> [...]
>> *) shared-serviceability
>> <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-serviceability/>
>>
>> - The usual code to support another GC
>
>> Hi Per,
>>
>>> Hi Roman,
>>>
>>> On 11/26/18 10:39 PM, Roman Kennke wrote:
>>> [...]
>>>> *) shared-serviceability
>>>> <http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-serviceability/>
>&g
tp://cr.openjdk.java.net/~rkennke/shenandoah-upstream/00/shared-tests/test/hotspot/jtreg/gc/metaspace/TestMetaspacePerfCounters.java.sdiff.html
> Also these tests are going to be run with all GC and fails if Shenandoah
> is not supported.
Right. I fixed those and a few others I have found. Th
Alright, we fixed:
- The minor issues that Kim reported in shared-gc
- A lot of fixes in shared-tests according to Leonid's review
- Disabled SA heapdumping similar to ZGC as Per suggested
Some notes:
Leonid: test/hotspot/jtreg/gc/TestFullGCCount.java was actually
correct. The @requires there mea
robably all the various ShenandoahCompareAndSwap etc
variants, which need to be subclasses of their
non-Shenandoah-counterparts, and I don't see how to change that.
Thanks for reviewing and helping!
Roman
>
> [1]
> http://hg.openjdk.java.net/jdk/jdk/file/157c1130b46e/make/hotspot/gensrc/Gens
r clarifying. Yeah, we already have a fix in shenandoah/jdk and
it will appear in next round of reviews.
Thanks,
Roman
> Thank you,
> Jini
>
> On 11/29/2018 3:59 AM, Roman Kennke wrote:
>> Alright, we fixed:
>> - The minor issues that Kim reported in shared-gc
>> - A
as
>
> if test "x$OPENJDK_TARGET_CPU_ARCH" = "xx86" || test
> "x$OPENJDK_TARGET_CPU" = "xaarch64" ; then
>
>
> But it's a matter of preference, if you do not want to change. Otherwise
> it looks good!
>
> /Magnus
>>
>> /
here:
>
> # Disable unsupported GCs for Zero
> if HOTSPOT_CHECK_JVM_VARIANT(zero); then
> DISABLED_JVM_FEATURES="$DISABLED_JVM_FEATURES epsilongc g1gc zgc"
> fi
>
> cheers,
> Per
>
> On 11/26/18 11:47 PM, Erik Joelsson wrote:
>> Build
Yes! Great! Patch looks good!
Roman
> At one point, it was decided that experimental VM features (such as ZGC)
> should be not be built by default. This policy was later
> changed/abandoned, so we should enable building of ZGC by default.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-821447
Hello all,
Thanks so far for all the reviews and support!
I forgot to update the 'round' yesterday. We are in round 3 now :-)
Also, I fixed the numbering of my webrevs to match the review-round. ;-)
Things we've changed today:
- We moved shenandoah-specific code out of .ad files into our own .ad
because that is what they are: diagnostic flags.
Makes sense?
Thanks,
Roman
> On 11/29/18 9:41 PM, Roman Kennke wrote:
> [...]
>> http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/03/
>
> Some comments (I didn't look at the compiler part):
>
>
> src/hotspo
>> Hi Per,
>>
>> Thanks for taking time to look at this!
>>
>> We will take care of all the issues you mentioned.
>>
>> Regarding the flags, I think they are useful as they are now. Shenandoah
>> can be run in 'passive' mode, which doesn't involve any concurrent GC
>> (iow, it runs kindof like Para
tionally) is definitely
>not acceptable.
>
>Thanks,
>Vladimir
>
>On 11/30/18 1:55 AM, Roman Kennke wrote:
>>>> Hi Per,
>>>>
>>>> Thanks for taking time to look at this!
>>>>
>>>> We will take care of all the issues you ment
Hi all,
here comes round 4 of Shenandoah upstreaming review:
This includes fixes for the issues that Per brought up:
- Verify and gracefully reject dangerous flags combinations that
disables required barriers
- Revisited @requires filters in tests
- Trim unused code from Shenandoah's SA impl
- Mo
hanks,
> Vladimir
>
> On 11/30/18 1:00 PM, Roman Kennke wrote:
>> Hi all,
>>
>> here comes round 4 of Shenandoah upstreaming review:
>>
>> This includes fixes for the issues that Per brought up:
>> - Verify and gracefully reject dangerous flags co
loopopts.cpp when you check
> is_ShenandoahBarrier(). And you don't do that in other files.
>
> Code in opto/macro.cpp is ugly but it is only the place so we can live
> with it I think.
>
> Thanks,
> Vladimir
>
> On 11/30/18 1:00 PM, Roman Kennke wrote:
>&
when you check
>>> is_ShenandoahBarrier(). And you don't do that in other files.
>>>
>>> Code in opto/macro.cpp is ugly but it is only the place so we can live
>>> with it I think.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>&
_gc,
> _shenandoah_traversal_gc,
> _shenandoah_upgrade_to_full_gc,
>
> ==> share/classes/sun/jvm/hotspot/runtime/VMOps.java
>
> It would be good to add 'ShenandoahOperation' to the VMOps enum (though
> it is probably not in sync now).
>
> Thank you,
&
Hi Per,
Thanks for looking again.
I've fixed the ordering in shenandoah-dev:
http://cr.openjdk.java.net/~rkennke/fix-macro-order/webrev.00/
and it will apear in the next round of webrevs.
Thanks,
Roman
> Hi Roman,
>
> On 11/30/18 10:00 PM, Roman Kennke wrote:
>> Hi a
Round 5 of Shenandoah review includes:
- A fix for the @requires tag in TestFullGCCountTest.java. It should be
correct now. We believe the CMS @requires was also not quite right and
fixed it the same.
It reads now: Don't run this test if:
- Actual GC set by harness is CMS *and* ExplicitGCInvokesC
Round 5 of Shenandoah review includes:
- A fix for the @requires tag in TestFullGCCountTest.java. It should be
correct now. We believe the CMS @requires was also not quite right and
fixed it the same.
It reads now: Don't run this test if:
- Actual GC set by harness is CMS *and* ExplicitGCInvokesC
> not make sense for Shenandoah (like it is for G1, ZGC, etc)?
I suppose it does. I will add it.
Thanks,
Roman
> Thank you,
> Jini.
>
>
> On 12/4/2018 12:57 AM, Roman Kennke wrote:
>> Round 5 of Shenandoah review includes:
>> - A fix for the @requires tag in TestFu
Hi Magnus,
>> I got reviews for shared-build, but an earlier version, so maybe makes
>> sense to look over this again. Erik J, Magnus?
>
> Build changes look good.
Thanks, Magnus!
Roman
Hi Per,
>> Round 5 of Shenandoah review includes:
>> - A fix for the @requires tag in TestFullGCCountTest.java. It should be
>> correct now. We believe the CMS @requires was also not quite right and
>> fixed it the same.
>>
>> It reads now: Don't run this test if:
>> - Actual GC set by harness i
Thanks, Leonid, for reviewing!
Roman
> Hi
>
> The shared tests changes looks good for me. Thank you for fixing and testing
> different combinations.
>
> Leonid
>
>> On Dec 3, 2018, at 11:10 PM, Roman Kennke wrote:
>>
>> Round 5 of Shenandoah review
moved to targeted JDK12 ~tomorrow. I intend/expect to push
Shenandoah during the next couple of days, unless somebody speaks up
until then :-)
Thanks,
Roman
>
> thanks,
> Coleen
>
> On 12/4/18 3:37 PM, Roman Kennke wrote:
>> Thanks, Leonid, for reviewing!
>>
>> Ro
Here comes round 6, possibly/hopefully the last round of webrevs for
upstreaming Shenandoah:
http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/06/
It incorporates:
- renames vm_operations_shenandoah* to shenandoahVMOperations*, as
suggested by Coleen
- reshuffles gcCause in shared-gc SA as
Zhengyu's and Thomas' TaskQueue stuff landed in jdk/jdk and we
integrated it into shenandoah/jdk and in the master patch and webrevs.
I'm updating the webrevs in-place in:
http://cr.openjdk.java.net/~rkennke/shenandoah-upstream/06/
This is going to be the final webrev that I intend to push on Mon
l: 73, passed: 72, failed: 1, skipped: 0
Am 08.12.18 um 12:33 schrieb Roman Kennke:
> Zhengyu's and Thomas' TaskQueue stuff landed in jdk/jdk and we
> integrated it into shenandoah/jdk and in the master patch and webrevs.
> I'm updating the webrevs in-place in:
>
>
ok by me. Thanks!
Roman
Am 13.12.18 um 14:58 schrieb Aleksey Shipilev:
> Bug;
> https://bugs.openjdk.java.net/browse/JDK-8215356
>
> There are lots of hotspot/tier1 tests on x86_32 caused by Shenandoah. This
> mode is experimental, and
> we can disable it without prejudice to make tests clean.
Isn't anything pushed to 12 (kindof) automatically pushed to 13 too,
eventually?
Roman
> I've seen this has just been pushed to 12 but I think we'd need this
> to 13 too, but:
>
> https://bugs.openjdk.java.net/browse/JDK-8217873
>
> has been resolved as duplicate.
>
> I can help reopening it a
(I am cross-posting this to build-dev and compiler-dev because this
contains some (trivial-ish) shared build and C2 changes. The C2 changes
are almost all reversals of Shenandoah-specific paths that have been
introduced in initial Shenandoah push.)
I would like to propose that we switch to what we
Thanks, Erik!
Roman
Build change looks good.
/Erik
On 2019-04-02 14:12, Roman Kennke wrote:
(I am cross-posting this to build-dev and compiler-dev because this
contains some (trivial-ish) shared build and C2 changes. The C2 changes
are almost all reversals of Shenandoah-specific paths that
ort
:-)
opto/loopnode.cpp new is_Phi check was added. Please, explain.
I'm not sure. I believe Roland did this. I'll let him comment on it.
I don't see other issues in C2 code.
:-)
Thanks,
Roman
Regards,
Vladimir
On 4/2/19 2:12 PM, Roman Kennke wrote:
(I am cross-posting
I don't think it should be part of this cleanup.
Fair enough.
I have run several tests today, and removing the is_Phi() call doesn't
seem to negatively impact Shenandoah.
Updated webrevs:
Incremental:
http://cr.openjdk.java.net/~rkennke/JDK-8221766/webrev.01.diff/
Full:
http://cr.openjdk.java
The main difference is that instead of ensuring correct invariant when
we store anything into the heap (e.g. read-barrier before reads,
write-barrier before writes, plus a bunch of other stuff), we ensure the
strong invariance on objects when they get loaded, by employing what is
currently our wri
On 4/2/19 10:12 PM, Roman Kennke wrote:
> > - No more need for object equals barriers.
>
> I'm pleased about that. I really hated the AArch64 Shenandoah CAS!
I'm sorry to disappoint you, but the CAS barrier is still needed. The
memory location may still legally hold a fro
On 4/7/19 7:18 PM, Roman Kennke wrote:
> > On 4/2/19 10:12 PM, Roman Kennke wrote:
> > > > - No more need for object equals barriers.
> > >
> > > I'm pleased about that. I really hated the AArch64 Shenandoah
> > > CAS!
> >
> > I&
The changes look good to me. Thanks!!
Roman
> http://cr.openjdk.java.net/~shade/8225048/webrev.01/
>
> Some history: Shenandoah used to support x86_32 in "passive" mode long time
> ago. This mode relies
> only on stop-the-world GC to avoid implementing barriers (basically, runs
> Degenerated G
This is a fall-out from my Shenandoah upstreaming work in JDK11, where
I made a similar change in order to separate-out Shenandoah parts from
JFR build when Shenandoah is disabled.
Currently, all JFR metadata is collected in a single metadata.xml file.
>From those, the build machinery generates he
a per JVM-features adds complexity with little added
> benefit from what I can see.
> Thanks
> Erik
>
> > On 23 Jul 2020, at 19:48, Roman Kennke wrote:
> >
> > This is a fall-out from my Shenandoah upstreaming work in JDK11,
> > where
> > I made a sim
ough as the side by side diff is already forcing a
> side
> scroll on my smaller monitor.
>
> /Erik
>
> On 2020-07-23 10:48, Roman Kennke wrote:
> > This is a fall-out from my Shenandoah upstreaming work in JDK11,
> > where
> > I made a similar change in order
s, so I would prefer if we can avoid
> doing this.
>
> Thanks
> Markus
>
> -Original Message-
> From: Roman Kennke
> Sent: den 23 juli 2020 22:29
> To: Erik Gahlin
> Cc: [email protected]; build-dev <
> [email protected]>
&g
On Thu, 10 Sep 2020 15:30:04 GMT, Monica Beckwith wrote:
>> ZGC and ShenandoahGC are two low latency GCs in OpenJDK HotSpot. We will
>> enable and run microbenchmarks and scaling
>> tests for both. After enabling, I ran JTRegs, a few micros, and SPECJBB2015
>> (heap and multi-JVM) scaling tests
Hello there,
I made some fixes to the build machinery to be able to build Shark:
http://cr.openjdk.java.net/~rkennke/shark-build-top/
http://cr.openjdk.java.net/~rkennke/shark-build-hotspot/
http://cr.openjdk.java.net/~rkennke/shark-build-jdk/
In particular, it does:
- Improve the sed command to
I just realized that I posted some unneeded stuff, and that the check
for ZERO *or* ZEROSHARK can be made simpler:
http://cr.openjdk.java.net/~rkennke/shark-build-jdk/webrev.01/
Roman
Am Mittwoch, den 07.01.2015 um 15:45 +0100 schrieb Roman Kennke:
> Hello there,
>
> I made some fix
Hi Erik,
> > I made some fixes to the build machinery to be able to build Shark:
> >
> > http://cr.openjdk.java.net/~rkennke/shark-build-top/
> Looks fine, but the generated configure script needs to be generated by
> the script as it also updates a timestamp inside the file. We will still
> nee
Hi Erik,
> >>> I made some fixes to the build machinery to be able to build Shark:
> >>>
> >>> http://cr.openjdk.java.net/~rkennke/shark-build-top/
> >> Looks fine, but the generated configure script needs to be generated by
> >> the script as it also updates a timestamp inside the file. We will s
Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
> On 2015-01-07 17:11, Roman Kennke wrote:
> > Hi Erik,
> >
> > Do you have a bug for this?
> > No.
> >
> > I haven't pushed any changes to JDK in a while. Is it possible in the
> >
Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
> On 2015-01-07 17:29, Roman Kennke wrote:
> > Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
> >> On 2015-01-07 17:11, Roman Kennke wrote:
> >>> Hi Erik,
> >>>
that into JDK9 if you think that's fine.
Best regards,
Roman
Am Mittwoch, den 07.01.2015 um 17:49 +0100 schrieb Erik Joelsson:
> On 2015-01-07 17:29, Roman Kennke wrote:
> > Am Mittwoch, den 07.01.2015 um 17:16 +0100 schrieb Erik Joelsson:
> >> On 2015-01-07 17:11, Roman Kenn
probably be removed.
>
> Would you still like me to push what you currently have to hs-rt?
>
> /Erik
>
> On 2015-01-07 21:21, Roman Kennke wrote:
> > Hi Erik,
> >
> > When I built Zero and Shark on my Raspberry Pi, I noticed another
> > problem when copying j
ls_zero.hpp: No such file or directory
>
> From what I can see, adfiles are not generated for zero or zeroshark
> builds, so the include should probably be removed.
>
> Would you still like me to push what you currently have to hs-rt?
>
> /Erik
>
> On 2015-01-07 21:21
Am Donnerstag, den 08.01.2015 um 21:20 +1000 schrieb David Holmes:
> On 8/01/2015 9:05 PM, Roman Kennke wrote:
> > Oh and notice that if you try to build it yourself, use a version of
> > LLVM < 3.5. In 3.5, C++11 is used/required, and OpenJDK doesn't support
> > C+
Hi David,
> > - In ciTypeFlow.cpp only include some files and code only when building
> > C2. I don't think that code makes sense outside of C2. (That's the issue
> > that you've seen).
>
> Looks okay but someone from compiler team needs to comment. There may be
> other code that need adjusting
, den 09.01.2015 um 15:27 +1000 schrieb David Holmes:
> Hi Roman,
>
> Commenting on the hotspot changes ...
>
> On 8/01/2015 9:01 PM, Roman Kennke wrote:
> > Hi Erik,
> >
> > I'm CC-ing hotspot-dev for review of Hotspot code related changes.
> >
> > Ye
nary blobs from:
http://download.java.net/openjdk/jdk7/
These contain a (relatively) small bunch of pieces that are not (yet)
open-sourced.
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra
...
> Left in the jdk install tree.
>
> ---
> Just a first guess at a basic idea as to how this could work...
>
> Please don't assume the above is also an implementation, it's the basic idea
> of having members of the forest identify themselves, and the idea
javac problem?) please redirect
as appropriate.
Cheers, Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com * Tel: +49-721-663 968-0
U
othing else, can you make the FontManager*.class files available
> for us to look at?
Sure. You can find them here:
http://kennke.org/~roman/fontmanagerclass.zip
Thanks, Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automate
_LoadLibrary.c:(.text+0x358): undefined reference to `AWTIsHeadless'
> collect2: ld returned 1 exit status
Make sure you have the latest official tree from the website. There have
been some recent patches from the J2D workspace that changed this (I
adjusted a patch of mine for this issue).
/Roman
s kind of problems. I'll keep you updated when I know which
changeset introduced that regression.
Cheers, Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Ge
n lingering around.
I'm so sorry for the noise and for stealing your time.
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com * T
directory
`/home/roman/src/OpenJDK/openjdk/jdk/make/java/java'
make[2]: *** [all] Error 1
make[2]: Leaving directory
`/home/roman/src/OpenJDK/openjdk/jdk/make/java'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/roman/src/OpenJDK/openjdk/jdk/make'
--
Dipl.-Inform. (F
Hi,
Am Montag, den 21.04.2008, 19:10 +0200 schrieb Thorbjørn Ravn Andersen:
> Kelly O'Hair skrev den 21-04-2008 18:11:
> >
> >
> > Roman Kennke wrote:
> >> Hi there,
> >>
> >> I've just setup a box with the soon-to-be-released Ubuntu 8.04
^
> > Note: Some input files use or override a deprecated API.
> > Note: Recompile with -Xlint:deprecation for details.
> > Note: Some input files use unchecked or unsafe operations.
> > Note: Recompile with -Xlint:unchecked for details.
> > 5 errors
> >
> >
>
I
think it would be very useful, not only because some group trees lag
behind, but also when somebody wants to build an older version of a
current tree. (Ideally, I'd think the build system should offer to fetch
a matching blob via ant's get-tag or wget...)
/Roman
--
Dipl.-Infor
s. And I was looking for a 0.7MB download, not
a 70MB download, but I guess that'll do the job as well.
> Also we should sync the 2D repo
Yeah.
Thanks
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Ha
Hi,
> and don't like the idea of being able to disable Nimbus
> because of this dependency.
Too many negations and ablebables for my parser... Oops. ;-)
/Roman
--
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated S
Hi,
first of all, I think this is a LCMS problem, so we should think about
how to fix this _upstream_, otherwise we end up maintaining a patched
version of lcms *shudder*.
Then I don't think it's a good idea to depend on such 'internal'
defines. One OS defines or not _LITTLE_ENDIAN, others (
1 - 100 of 113 matches
Mail list logo
