Re: general inlining
On 02/16/10 07:04 PM, Raffaello Giulietti wrote: I asked because this kind of inlining seems quite clever to my uneducated eyes. Inlining, in m() or at other call sites, only a part of ensureSomething() while skipping the other heavier part and morphing it to another callable method appears quite a wonder without hints from part of the programmer in form of objects like method handles and the guarded counterparts. Kudos to the implementors! It's not that complicated if you have call profiles :-) But I admit that inlining heuristics could be even better in HotSpot. -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: Rebased to jdk7-b83.
Changeset: 9e6a20f84575 Author:twisti Date: 2010-02-16 10:14 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9e6a20f84575 Rebased to jdk7-b83. ! indy-c1-x86-6919934.patch ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/jdk: Rebased to jdk7-b83.
Changeset: 9e7142d8da87 Author:twisti Date: 2010-02-16 10:14 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/9e7142d8da87 Rebased to jdk7-b83. ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: indy-c1-x86-6919934: SPARC build fixes.
Changeset: 41443854c6c5 Author:twisti Date: 2010-02-16 10:31 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/41443854c6c5 indy-c1-x86-6919934: SPARC build fixes. ! indy-c1-x86-6919934.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: general inlining
On 02/16/10 03:07 PM, Raffaello Giulietti wrote:
A general question about inlining. Take the following code:
void m() {
ensureSomething();
...
}
void ensureSomething() {
if (someTest()) return;
doSomething();
}
boolean someTest() {
return ... // a simple boolean expression;
}
void doSomething() {
// heavy and long code
...
}
I would like the lightweight test in ensureSomething(), but not the
heavy doSomething(), to be inlined at each call site, like that in m().
Is a general jvm (HotSpot in primis) smart enough to do the inlining by
itself or is it better to code the pattern more explicitly by using
method handles to factor out the test, e.g., using guarded method handles?
If doSomething() is heavy enough to not be inlined (or cold) and
someTest() is light enough to be inlined (or hot) in regard to the
inlining heuristics, yes, the JVM should do the right thing for you.
You can verify if HotSpot does what you want with:
-XX:+PrintCompilation -XX:+PrintInlining
-- Christian
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: deopt-mh-6921352.patch: New patch as pushed to jdk7/ hotspot-comp/.
Changeset: 208811eec443 Author:twisti Date: 2010-02-15 14:44 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/208811eec443 deopt-mh-6921352.patch: New patch as pushed to jdk7/ hotspot-comp/. dont-fixup-6921799.patch: Likewise. series: Added above files. callcc.patch: Updated indy-c1-x86-6919934.patch: Likewise. ! callcc.patch + deopt-mh-6921352.patch + dont-fixup-6921799.patch ! indy-c1-x86-6919934.patch ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: callcc: Fixed compilation.
Changeset: 50f6c2cbdea6 Author:twisti Date: 2010-02-15 15:19 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/50f6c2cbdea6 callcc: Fixed compilation. ! callcc.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: series: Enabled indy-c1-x86-6919934 by default.
Changeset: 3736c05ba9e9 Author:twisti Date: 2010-02-15 15:21 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/3736c05ba9e9 series: Enabled indy-c1-x86-6919934 by default. ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
[laptop-discuss] resume time
On 02/10/10 04:48 PM, Dave Miner wrote:
I tried to do this with an OpenSolaris live USB but I can't get the
right driver to be attached. I'm changing /etc/driver_aliases in
solarismisc.zlib but it seems that one is not used when I boot the
system from live USB.
No, it's not. The root file system when booted from the CD or USB is
the boot archive, /platform/i86pc{/amd64}/boot_archive.
Wow, I can't believe it, I got it. Resume time is down to about 8
seconds. Thanks for all your help.
-- Christian
[laptop-discuss] resume time
On Tue, 2009-11-17 at 15:48 -0500, Albert Lee wrote: Alternatively I think you could just get a live USB or SXCE failsafe image. http://solaristhings.blogspot.com/2006/07/how-small-can-you-make-open-solaris.html explains how to modify the SXCE failsafe image - procedure should be similar for live USB. You need to modify its /etc/driver_aliases: # echo 'pci10de,ab5 ahci' basedir/etc/driver_aliases (no other entry should be needed because the PCI ID is always matched before the PCI class). Then on the installed system do: # update_drv -a -i 'pci10de,ab5' ahci; touch /reconfigure The driver will fail to attach but that's expected. If you're using the live USB, then: # zpool import -f rpool; beadm mount BE name /a; devfsadm -C -r /a; bootadm update-archive -R /a -f; beadm umount /a; reboot With SXCE failsafe: # zpool import -f rpool; zfs mount rpool/ROOT/BE name /a; devfsadm -C -r /a; bootadm update-archive -R /a -f; zfs umount /a; reboot (don't export the pool) I tried to do this with an OpenSolaris live USB but I can't get the right driver to be attached. I'm changing /etc/driver_aliases in solarismisc.zlib but it seems that one is not used when I boot the system from live USB. -- Christian
Re: hg: mlvm/mlvm/hotspot: dynopt, trustfinal: update to match JDK7 pushes
On 02/ 1/10 08:31 AM, Charles Oliver Nutter wrote:
I think I lost track of patches for a while...trustfinal is the
optimization to not repeatedly access finals, correct? I'll have a
look at the patch, but perhaps a description of when final accesses
will be elided?
This patch adds a command line option (-XX:+TrustFinalNonStaticFields)
to turn on for user classes what we already do for system classes in
{java,sun}.dyn: treat final non-static fields as constants.
This enables to inline MethodHandle chains completely that e.g. have a
GuardWithTest in between.
-- Christian
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: series: Rebased to jdk7-b81.
Changeset: b9c4ee26ce76 Author:twisti Date: 2010-02-01 10:09 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b9c4ee26ce76 series: Rebased to jdk7-b81. osxpaths.patch: Removed. - osxpaths.patch ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/jdk: series: Rebased to jdk7-b81.
Changeset: f8750be16e41 Author:twisti Date: 2010-02-01 10:10 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/f8750be16e41 series: Rebased to jdk7-b81. osxpaths.patch: Removed. - osxpaths.patch ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/langtools: series: Rebased to jdk7-b81.
Changeset: 5e88ba2b38fc Author:twisti Date: 2010-02-01 10:11 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/5e88ba2b38fc series: Rebased to jdk7-b81. ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: JSR 292 x86 C1 support
On 01/28/10 02:07 PM, Christian Thalinger wrote:
It should also work as final non-static field and using -XX:
+TrustFinalNonStaticFields. That switch does for user classes what
happens per default for {java,sun}.dyn classes: we trust final
non-static to be effectively final. But it does not work and I don't
know yet why.
My fault. It does work but the MH chain has to start with a MH that the
compiler can guarantee to be a constant. Then final non-static fields
in user classes in the chain can also be inlined.
-- Christian
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: indy-c1-x86: Renamed to indy-c1-x86-6919934.
Changeset: 7a6d77330310 Author:twisti Date: 2010-02-01 14:36 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/7a6d77330310 indy-c1-x86: Renamed to indy-c1-x86-6919934. + indy-c1-x86-6919934.patch - indy-c1-x86.patch ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: hg: mlvm/mlvm/hotspot: dynopt, trustfinal: update to match JDK7 pushes
On 02/ 1/10 03:48 PM, Charles Oliver Nutter wrote:
On Mon, Feb 1, 2010 at 2:41 AM, Christian Thalinger
christian.thalin...@sun.com wrote:
This patch adds a command line option (-XX:+TrustFinalNonStaticFields)
to turn on for user classes what we already do for system classes in
{java,sun}.dyn: treat final non-static fields as constants.
This enables to inline MethodHandle chains completely that e.g. have a
GuardWithTest in between.
Ok, then it is the work I discussed with John and Tom Rodriguez some
time ago. I'll have to play with it; in JRuby's normal mode (non-indy)
there are a number of final accesses that could potentially go away
with this. I think Tom ran some numbers and didn't see improvement,
but he did not have any of JRuby's more experimental flags turned on.
Right, I remember the discussion. Let me know if I can help.
-- Christian
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
[indiana-discuss] gnome-terminal heavily disk-reads on scroll-back
Sometimes gnome-terminal does heavy disk-reads when I scroll-back the buffer with a actually not very big scroll-back size and it doesn't get less when I scroll the same region. So I guess it's not swapping or something similar. This also happens with a newly started gnome-terminal instance. Does anyone else see this problem with current builds? -- Christian ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] gnome-terminal heavily disk-reads on scroll-back
On Thu, 2010-01-28 at 11:51 +0100, Christian Thalinger wrote: Sometimes gnome-terminal does heavy disk-reads when I scroll-back the buffer with a actually not very big scroll-back size and it doesn't get less when I scroll the same region. So I guess it's not swapping or something similar. This also happens with a newly started gnome-terminal instance. Does anyone else see this problem with current builds? It also happens from time to time when I type in the console. Wow, this is annoying... -- Christian ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] gnome-terminal heavily disk-reads on scroll-back
On 01/28/10 06:44 PM, Shawn Walker wrote: On 01/28/10 04:51 AM, Christian Thalinger wrote: Sometimes gnome-terminal does heavy disk-reads when I scroll-back the buffer with a actually not very big scroll-back size and it doesn't get less when I scroll the same region. So I guess it's not swapping or something similar. This also happens with a newly started gnome-terminal instance. Does anyone else see this problem with current builds? So how much memory do you have in this system? I'm not seeing this behaviour on b130, but I have 8GB of memory. I have 4GB. I think that should be enough for a little scroll-back. -- Christian ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] gnome-terminal heavily disk-reads on scroll-back
On 01/28/10 07:30 PM, Shawn Walker wrote: On 01/28/10 12:26 PM, Christian Thalinger wrote: On 01/28/10 06:44 PM, Shawn Walker wrote: On 01/28/10 04:51 AM, Christian Thalinger wrote: Sometimes gnome-terminal does heavy disk-reads when I scroll-back the buffer with a actually not very big scroll-back size and it doesn't get less when I scroll the same region. So I guess it's not swapping or something similar. This also happens with a newly started gnome-terminal instance. Does anyone else see this problem with current builds? So how much memory do you have in this system? I'm not seeing this behaviour on b130, but I have 8GB of memory. I have 4GB. I think that should be enough for a little scroll-back. What build are you on? This is on 131. Do you know for certain that gnome-terminal is responsible for the disk activity? I'm not absolutely sure, but when I scroll the terminal for one line it starts loading as hell. But I have a feeling that maybe Evolution is the source of all that... Have you checked with DTrace or another tool? No, I don't know how to do that. Sorry. Have you checked to see how much free memory top says your system has whenever you see this behaviour? I did, yes. IIRC it was something around 2GB. Is the free memory reported by top accurate? -- Christian ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: JSR 292 x86 C1 support
On Wed, 2010-01-27 at 17:59 +0100, Rémi Forax wrote: Nice, it works well on some my small test suites (MethodHandle and indy). Thanks for testing. About perf, dynamic calls are a little less efficient than their static couterparts, it seems that neither c1 nor c2 inline a method handle call or an invokedynamic. Should I have set these inline flags that are now in product VM ? It's correct that C1 does not do inlining for MH call sites, but C2 should. Could you try to run with -XX:+PrintCompilation -XX: +PrintInlining to see why the methods are not inlined? -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: JSR 292 x86 C1 support
On Thu, 2010-01-28 at 12:15 +0100, Rémi Forax wrote: Le 28/01/2010 11:34, Christian Thalinger a écrit : On Wed, 2010-01-27 at 17:59 +0100, Rémi Forax wrote: Nice, it works well on some my small test suites (MethodHandle and indy). Thanks for testing. About perf, dynamic calls are a little less efficient than their static couterparts, it seems that neither c1 nor c2 inline a method handle call or an invokedynamic. Should I have set these inline flags that are now in product VM ? It's correct that C1 does not do inlining for MH call sites, but C2 should. Could you try to run with -XX:+PrintCompilation -XX: +PrintInlining to see why the methods are not inlined? With the test in attachment java -server -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic Test2 (-server is jdk7b80 hs17) Clearly the method handle aren't inlined, PrintInlining give me some cryptic values (encoding problem I think), I've also testes with LogCompilation, I get: bc code='182' bci='44'/ type id='572' name='int'/ method id='938' holder='691' name='invoke' return='572' arguments='572' flags='4369' bytes='0' iicount='1'/ call method='938' count='11264' prof_factor='1' inline='1'/ inline_depth_discount caller='905' callee='938'/ direct_call bci='44'/ uncommon_trap bci='44' reason='null_check' action='maybe_recompile'/ (and from javap) 44: invokevirtual #21 // Method java/dyn/MethodHandle.invoke:(I)I The whole log is is attachment, with the test. Sorry, I didn't see the attachment with the previous email. I'll look into it. -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: JSR 292 x86 C1 support
On Thu, 2010-01-28 at 13:45 +0100, Christian Thalinger wrote:
Sorry, I didn't see the attachment with the previous email. I'll look
into it.
OK, I'm a bit puzzled. One obvious thing that does not work is that
increment is a local variable. Inlining only works if the MH is a
static or instance variable. Changing increment to be a final static
and (now the puzzling part) using -XX:ScavengeRootsInCode=2 works:
Direct (10): 0
Handle (10): 0
I thought that we already default to ScavengeRootsInCode=2, at least
with MethodHandles enabled, but obviously we do not.
It should also work as final non-static field and using -XX:
+TrustFinalNonStaticFields. That switch does for user classes what
happens per default for {java,sun}.dyn classes: we trust final
non-static to be effectively final. But it does not work and I don't
know yet why.
-- Christian
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
JSR 292 x86 C1 support
Hi! Yesterday I committed the first draft of the x86 C1 implementation for JSR 292. I did some testing on Linux and Solaris with the JRuby tests and benchmarks. The current implementation can run all but one benchmarks (bench/bench_fib_stack_depth.rb, I still have to look into it) successfully and finishes all 214 tests (test/test*.rb). The latter means that all tests run to its end and do not crash or assert, I have no comparison yet if they finish successfully. It would be very helpful if people out there would test their indy'fied language implementation or just simple MH or invokedynamic testcases with the client compiler. It would also be very helpful to get pointers to other testsuites than JRuby. The more tests, the better. The easiest way to give it a try is to only build HotSpot and copy the libjvm into a JDK 7 b80 download (given you are on Windows, Linux or Solaris). Thanks for you help! -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: bug in gaming with MLVM
On Tue, 2010-01-26 at 09:46 +0100, Daniel Latrémolière wrote: C:\Users\daniel\Documents\NetBeansProjects\Test\srcC:\Program Files\Java\jdk1.7.0\bin\java.exe -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles -XX:+EnableInvokeDynamic Test Direct (10): 313 Handle (25740): 133 Direct (10): 228 Handle (12496): 32 Direct (10): 222 Handle (1): -26146065545629 Direct (10): 221 Handle (1): -26146065545349 Direct (10): 222 Handle (1): -26146065545069 Direct (10): 220 Handle (1): -26146065544790 C:\Users\daniel\Documents\NetBeansProjects\Test\srcC:\Program Files\Java\jdk1.7.0\bin\java.exe -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles -XX:+EnableInvokeDynamic Test Direct (10): 311 Handle (25740): 137 Direct (10): 228 Handle (12496): 32 Direct (10): 223 # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x6d965f33, pid=1008, tid=3012 # # JRE version: 7.0-b80 # Java VM: Java HotSpot(TM) Client VM (17.0-b07 mixed mode, sharing windows-x86 ) # Problematic frame: # V [jvm.dll+0xb5f33] # # An error report file with more information is saved as: # C:\Users\daniel\Documents\NetBeansProjects\Test\src\hs_err_pid1008.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I took me some time to see the actual problem: there's no JSR 292 support for the client compiler yet. I'm currently working on that and it's almost finished. To successfully run your test use the server compiler: java.exe -server -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles -XX:+EnableInvokeDynamic Test -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: bug in gaming with MLVM
On Tue, 2010-01-26 at 10:45 +0100, Rémi Forax wrote: Christian and John, I've also noticed that the code written should not compile, invoking a method handle with invoke() can throw any throwable and it seems that javac patch to require to catch/throws Throwable was not pushed to jdk7 main workspace. I think you're right. John is taking care of the jdk and langtools patches and honestly I don't know why they haven't been pushed yet. Maybe there's still some EG decision missing? -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: indy-c1-x86: New patch.
Changeset: d6dbb6e6c4b2 Author:twisti Date: 2010-01-26 14:41 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/d6dbb6e6c4b2 indy-c1-x86: New patch. + indy-c1-x86.patch ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/langtools: Rebased to jdk7-b80.
Changeset: 3e09eb425736 Author:twisti Date: 2010-01-25 14:23 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/3e09eb425736 Rebased to jdk7-b80. ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: Rebased to jdk7-b79.
Changeset: 4bee1e17fdf0 Author:twisti Date: 2010-01-22 12:55 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/4bee1e17fdf0 Rebased to jdk7-b79. ! disassembler-6912062.patch ! indy.compiler-6829187.patch ! meth.walker-6894206.patch ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/jdk: Rebased to jdk7-b79.
Changeset: bbf07c30e0fc Author:twisti Date: 2010-01-22 12:55 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/bbf07c30e0fc Rebased to jdk7-b79. ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/langtools: Rebased to jdk7-b79.
Changeset: 80924b747ad5 Author:twisti Date: 2010-01-22 12:55 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/80924b747ad5 Rebased to jdk7-b79. ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: dynopt-6912064: Rebased to jdk7-b79.
Changeset: ff47ce9e949e Author:twisti Date: 2010-01-22 13:01 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ff47ce9e949e dynopt-6912064: Rebased to jdk7-b79. ! dynopt-6912064.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: meth.walker-6894206: Removed duplicate insert_before.
Changeset: ab204054bfb4 Author:twisti Date: 2010-01-22 13:31 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ab204054bfb4 meth.walker-6894206: Removed duplicate insert_before. ! meth.walker-6894206.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: compiling mlvm: error rebuilding libjava.dylib
On Mon, 2010-01-18 at 15:09 -0500, Stephen Bannasch wrote: On Mon, 2010-01-11 at 10:32 -0500, Stephen Bannasch wrote: I've never seen this error. What happens when you try to print the archive contents manually (with: ar t archive)? $ ar -t java/src/bsd-port/build/bsd-i586/tmp/java/fdlibm/obj/libfdlibm.i586.a k_standard.o k_rem_pio2.o k_cos.o ... Search machines suggest to run ranlib(1) on the archive. You should probably ask on bsd-port-dev, people there should know more about Mac OS X build problems. Sorry. Thanks for that tip Christian. ar was not building the catalog file for the archive because the environmental variable COMMAND_MODE was set to 'legacy'. This occurred because I recently switched from the Mac OS X Terminal program to iTerm because of iTerms much better handling ofcolored and styled fonts. Without another action COMMAND_MODElagacy when starting up a console shell on Mac OS X using iTerm. I think most people use Terminal.app in Mac OS X so aren't affected by this problem. In any case I updated my build script here: http://gist.github.com/243072 To change the COMMAND_MODE to unix2003 if it is set to legacy references: http://old.nabble.com/Why-ar-doesn't-call-ranlib-on-Mac--td22319721.html Cool you actually found out what the problem was. -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: compiling mlvm: error rebuilding libjava.dylib
On Sat, 2010-01-09 at 16:52 -0500, Stephen Bannasch wrote: I'm getting an error re-building mlvm on MacOS 10.5.8 (haven't tried it on another os yet). I'm using this script when I rebuild: http://gist.github.com/243072 This build script last worked fine at the end of November -- the only changes I have made since then are to console output. After finishing the parallel compiles for jdk and starting to rebuild libjava.dylib: Done with parallel compiles: /Users/stephen/dev/java/src/bsd-port/jdk/make/java/java STATS: LIBRARY=java, PRODUCT=java, OPTIMIZATION_LEVEL=HIGHER Rebuilding /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/lib/i386/libjava.dylib because of /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/tmp/java/java.lang/java/obj/.files_compiled ld reports the following error rebuilding libjava.dylib: libfdlibm.i586.a, archive has no table of contents ld: in /Users/stephen/dev/java/src/bsd-port/build/bsd-i586/tmp/java/fdlibm/obj/libfdlibm.i586.a, archive has no table of contents collect2: ld returned 1 exit status make[4]: *** [/Users/stephen/dev/java/src/bsd-port/build/bsd-i586/lib/i386/libjava.dylib] Error 1 make[3]: *** [all] Error 1 make[2]: *** [all] Error 1 make[1]: *** [jdk-build] Error 2 make: *** [build_product_image] Error 2 [1]+ Donerm -i -rf build.del The complete gcc invocation for rebuilding libjava.dylib can be seen here: http://gist.github.com/273127 Any ideas where I should look further? I've never seen this error. What happens when you try to print the archive contents manually (with: ar t archive)? -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: compiling mlvm: error rebuilding libjava.dylib
On Mon, 2010-01-11 at 10:32 -0500, Stephen Bannasch wrote: I've never seen this error. What happens when you try to print the archive contents manually (with: ar t archive)? $ ar -t java/src/bsd-port/build/bsd-i586/tmp/java/fdlibm/obj/libfdlibm.i586.a k_standard.o k_rem_pio2.o k_cos.o ... Search machines suggest to run ranlib(1) on the archive. You should probably ask on bsd-port-dev, people there should know more about Mac OS X build problems. Sorry. -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/jdk: Rebased to jdk7-b78.
Changeset: bf2a5241b0d6 Author:twisti Date: 2010-01-07 13:54 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/bf2a5241b0d6 Rebased to jdk7-b78. ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/langtools: Rebased to jdk7-b78.
Changeset: 48844e4189d1 Author:twisti Date: 2010-01-07 14:10 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/langtools/rev/48844e4189d1 Rebased to jdk7-b78. ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: meth.walker-6894206: Commited to hotspot-comp.
Changeset: effbcde0861f Author:twisti Date: 2010-01-05 11:34 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/effbcde0861f meth.walker-6894206: Commited to hotspot-comp. ! meth.walker-6894206.patch ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: 3 new changesets
Changeset: ecfd03ae5c1f Author:twisti Date: 2009-12-16 17:40 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ecfd03ae5c1f indy-cleanup-6893081: Review changes, round 3. ! indy-cleanup-6893081.patch Changeset: 5ee7867ad426 Author:twisti Date: 2010-01-05 11:39 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/5ee7867ad426 Merge - disassembler.patch - dynopt.patch - indy-amd64.patch - indy.compiler.inline.patch - indy.compiler.patch - inlines.patch - meth.walker.patch Changeset: a0fbb18d8976 Author:twisti Date: 2010-01-05 11:41 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a0fbb18d8976 series: indy-cleanup-6893081 commited to hotspot-comp. ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: series: indy.compiler-6829187 commited to hotspot-comp.
Changeset: 0aec7b5b7bf3 Author:twisti Date: 2010-01-05 12:27 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/0aec7b5b7bf3 series: indy.compiler-6829187 commited to hotspot-comp. ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: 3 new changesets
Changeset: aa7e98ee3bc4 Author:twisti Date: 2010-01-05 12:58 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/aa7e98ee3bc4 indy.compiler.inline-6893268: Last review round plus John's changes. ! indy.compiler.inline-6893268.patch Changeset: 147953c10b6a Author:twisti Date: 2010-01-05 13:06 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/147953c10b6a indy.compiler-6829187: Added Matcher::method_handle_invoke_SP_save_mask on SPARC. ! indy.compiler-6829187.patch Changeset: c61ad2d1ab62 Author:twisti Date: 2010-01-05 13:06 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/c61ad2d1ab62 Merge ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: 2 new changesets
Changeset: f274265b57ce Author:twisti Date: 2010-01-05 15:14 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f274265b57ce indy.compiler.inline-6893268: Removed Matcher::method_handle_invoke_SP_save_mask since it was integrated with 6829187. ! indy.compiler.inline-6893268.patch Changeset: 8be1140de6bd Author:twisti Date: 2010-01-05 15:15 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/8be1140de6bd Merge ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: series: indy.compiler.inline-6893268 commited to hotspot-comp.
Changeset: 3c1bb69c86ae Author:twisti Date: 2010-01-05 16:34 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/3c1bb69c86ae series: indy.compiler.inline-6893268 commited to hotspot-comp. ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: meth.walker.fixes: Renamed to meth.walker.fixes-6914206.
Changeset: 7b471614b25a Author:twisti Date: 2010-01-05 17:49 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/7b471614b25a meth.walker.fixes: Renamed to meth.walker.fixes-6914206. + meth.walker.fixes-6914206.patch - meth.walker.fixes.patch ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [indiana-discuss] b130
On Fri, 2009-12-25 at 13:30 -0500, Paul Gress wrote: On 12/25/09 05:38 AM, dick hoogendijk wrote: pfexec pkg install SUNWipkg - 750 new pkgs / 347 MB Is this normal if I want to renew one(1) pkg? This is more like an image-uodate which was refused because an out-of-date SUNWipkg (from b129) Sounds like your getting the error: http://defect.opensolaris.org/bz/show_bug.cgi?id=13233 Try the following command: pkg contents -Ho pkg.name,action.raw -t depend | grep fmri=entire@ | cut -f1 If you get output, you need to remove these packages (from contrib) to upgrade to b130. I have the same problem but I don't get output from this command. What else could be the problem? -- Christian ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] syseventd core dumps after resume on b129
On Fri, 2009-12-18 at 19:34 -0800, Ivan Wang wrote: Hi all, Not sure if it's a known issue, I didn't find it at d.o.o. The thing is I tried putting a system with ASUS P6TD Deluxe and nvidia graphics into S3 then resume back. The system did enter S3, though after resume. It is 100 reproducible that syseventd core dumps. Core shows syseventd is sent with SIGABRT which made it looks like syseventd is killed deliberately. Have this been spotted before? http://defect.opensolaris.org/bz/show_bug.cgi?id=13397 -- Christian ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) StrictMath.ceil(double)
On Mon, 2009-12-14 at 01:31 -0800, Joseph D. Darcy wrote: Hello. Please review my fix for 6908131 Pure Java implementations of StrictMath.floor(double) StrictMath.ceil(double) http://cr.openjdk.java.net/~darcy/6908131.0/ I've asked Doug Priest, one of Sun's numerical experts, to review the floor/ceil algorithm and testing. I've incorporated his feedback and he has approved those aspects of the changes. The JDK integration has not yet been looked over. Not a review, but did you think about implementing the whole FDLIBM in Java, as done here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001970.html -- Christian
Re: Code review request for 6908131 Pure Java implementations of StrictMath.floor(double) StrictMath.ceil(double)
On Mon, 2009-12-14 at 10:16 -0800, Joseph D. Darcy wrote: Not a review, but did you think about implementing the whole FDLIBM in Java, as done here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2009-August/001970.html Yes, porting FDLIBM to Java has been an oft-delayed nice to have project of mine. It is not obvious from looking at my ceil/floor code, but it started with the FDLIBM versions of those algorithms. The tests are new and greatly outnumber the code changes, as it typical in this line of work :-) I think getting an all-java StrictMath library would be best done as a series of small batches so floor/ceil could be a start. All in all sounds good :-) -- Christian
Re: [indiana-discuss] What to do with missing arial fonts ?
On Thu, 2009-12-10 at 18:00 +0100, Detlef Drewanz wrote: 2. Install the arial fonts again ? But what's the best place now ? Is there a ~/.xyz directory which will be scanned for fonts automatically or do I have to create an entry in /etc/X11/fontpath.d by myself ? Any comments, best practices ideas ? I put my fonts in ~/.fonts and they are picked up automatically. Aha, good. Just putting the fonts there is enough, or is also mkfontdir required ? I think putting the font there is enough (maybe restart X, I don't know). -- Christian ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: Cross Compiling for x86_64 on x86
On Mon, 2009-12-07 at 14:55 +0530, Deepak Mathews wrote: Can the building of OpenJDK made independant of the host machine. Or does it run some programs which are dependant (like adlc) which will make cross compilation impossible? What about cross compiling for MIPS or PPC from the same 32 bit host? Will this same VM problem be there for that also? There problem here is ADLC, which is part of the server compiler. Let me try to get it built for a 32-bit host... Cross-compiling IcedTea for MIPS or PPC should work OK, as there is no server or client compiler port so Zero is used and that builds fine. You could also build x86_64 Zero (Gary, does that work?) on your 32-bit system and use that one. But keep in mind that it's C++ interpreter only. -- Christian
Re: Cross Compiling for x86_64 on x86
On Mon, 2009-12-07 at 10:39 +0100, Christian Thalinger wrote: There problem here is ADLC, which is part of the server compiler. Let me try to get it built for a 32-bit host... A really ugly (but possibly working) hack to build a full OpenJDK successfully would be to copy a 32-bit adlc over the 64-bit one when the build fails: $ cp build/solaris/solaris_i486_compiler2/generated/adfiles/adlc build/solaris/solaris_amd64_compiler2/generated/adfiles/adlc Then just restart the build. -- Christian
Re: Character.java methods are slower than Surrogate.java's
On Wed, 2009-10-28 at 22:44 +0100, Ulf Zibis wrote: Hi Christian, for a benchmark test I have replaced all sun.nio.cs.Surrogate methods in sun.nio.cs.ext.EUC_TW with corresponding ones from java.lang.Character. As result, the overall encoding performance was 10 % worse, so java.lang.Character's methods must be much worser. Can you have a look, if there is a chance to better optimize java.lang.Character methods from HotSpot compiler side. I think you're already looking into this yourself. -- Christian
Re: [indiana-discuss] OpenSolaris package repository update, development build 127, x86/x64/SPARC (15 new packages)
On Fri, 2009-12-04 at 17:14 +, Chris Ridd wrote: On 15 Nov 2009, at 12:57, Sebastien Roy wrote: On Sun, 2009-11-15 at 12:30 +0100, Christian Thalinger wrote: On Fri, 2009-11-13 at 18:21 -0800, david.co...@sun.com wrote: The OpenSolaris development package repository http://pkg.opensolaris.org/dev/ has been updated to reflect the changes up to and including snv_127 for both x86/x64 and SPARC platforms. This update includes fixes to the Caiman Slim Install and the Image Packaging System (IPS). Did something change with font rendering? The hinting is completely different and I have to turn it *off* to get similar fonts as on snv_126. I saw this and reported it. The folks responsible for fonts are looking into it (I don't have a bug filed yet). Font rendering is still affected in 128a - did a bug get raised for this? Although you can disable hinting and get GNOME apps looking OK again, things like Thunderbird and Firefox still look wrong. Right, same for me. -- Christian ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
hg: mlvm/mlvm/hotspot: indy.compiler.inline: Review changes, round 2.
Changeset: 761081d6e5a8 Author:twisti Date: 2009-12-03 11:53 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/761081d6e5a8 indy.compiler.inline: Review changes, round 2. ! indy.compiler.inline.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: indy.compiler.inline: Build fix.
Changeset: 101f44f31522 Author:twisti Date: 2009-12-03 07:23 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/101f44f31522 indy.compiler.inline: Build fix. ! indy.compiler.inline.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: indy.compiler.inline: Missed a hg qref.
Changeset: 74b2b52ed9cf Author:twisti Date: 2009-12-03 07:37 -0800 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/74b2b52ed9cf indy.compiler.inline: Missed a hg qref. ! indy.compiler.inline.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: indy.compiler.inline: Review changes, round 1.
Changeset: 1563d278668d Author:twisti Date: 2009-12-02 12:26 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/1563d278668d indy.compiler.inline: Review changes, round 1. ! indy.compiler.inline.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: indy-cleanup-6893081: Review changes, round 2.
Changeset: ce21d48f4c1f Author:twisti Date: 2009-12-02 16:19 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ce21d48f4c1f indy-cleanup-6893081: Review changes, round 2. ! indy-cleanup-6893081.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: 2 new changesets
Changeset: 9dbabeb9c96d Author:twisti Date: 2009-12-01 11:04 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9dbabeb9c96d indy.compiler.inline: Disable debug output. ! indy.compiler.inline.patch Changeset: 63172a745a90 Author:twisti Date: 2009-12-01 12:11 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/63172a745a90 callcc: Fixed compilation. ! callcc.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
fixed callcc [Was: Re: hg: mlvm/mlvm/hotspot: 2 new changesets]
On Tue, 2009-12-01 at 11:12 +, christian.thalin...@sun.com wrote: Changeset: 63172a745a90 Author:twisti Date: 2009-12-01 12:11 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/63172a745a90 callcc: Fixed compilation. ! callcc.patch I fixed a couple of problems I encountered on Solaris with Sun Studio. I wonder how this could ever build with Visual Studio and GCC... -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: meth.walker: Review changes, round 1.
Changeset: ce986a2e6ec7 Author:twisti Date: 2009-12-01 15:54 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/ce986a2e6ec7 meth.walker: Review changes, round 1. ! meth.walker.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: indy-cleanup-6893081: Review changes, round 1.
Changeset: afebc5c4 Author:twisti Date: 2009-12-01 16:37 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/afebc5c4 indy-cleanup-6893081: Review changes, round 1. ! indy-cleanup-6893081.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: indy.compiler: Review changes, round 1.
Changeset: 856a5f570a77 Author:twisti Date: 2009-12-01 17:57 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/856a5f570a77 indy.compiler: Review changes, round 1. ! indy.compiler.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: indy-cleanup-6893081: Refreshed w/o funcs (sorry).
Changeset: b298137a8a42 Author:twisti Date: 2009-12-01 18:01 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b298137a8a42 indy-cleanup-6893081: Refreshed w/o funcs (sorry). ! indy-cleanup-6893081.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: meth.walker: Moved new check to right place.
Changeset: 8e76103d8cc3 Author:twisti Date: 2009-12-01 18:24 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/8e76103d8cc3 meth.walker: Moved new check to right place. ! meth.walker.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [indiana-discuss] gstreamer not installed?
On Fri, 2009-11-27 at 09:19 +0100, Gilles Gravier wrote: Hi! Just tried to run a ./configure for aMSN ... and I get you do not seem to have gstreamer and farsight2 installed. So... I agree for farsight2... but I do have gstreamer libs installed. My gues is that it's missing -dev packages somewhere. Question is which SUNWx package brings the equivalent of a -dev for gstreamer (I imagine the header files)? A simple: $ pkg search -r gst.h returns SUNWgnome-media, so the headers are in the same package as the gstreamer libraries. -- Christian ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: mlvm don't build
On Tue, 2009-11-24 at 23:29 -0500, Stephen Bannasch wrote: On Mon, 2009-11-16 at 11:03 +0100, Raffaello Giulietti wrote: But currently the patch queue is not in a state that allow to play with it, because method handle and indy patchs are in the review process in order to be integrated in hotspot main workspace. I think we have to wait the end of the sync with the main workspace before to be able to play again with indy patches. Rémi I see. So, let's wait for more stable changesets. I can't build davinci also. I just did a clean build with current bsd-port and mlvm patches. No problems. -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: mlvm don't build
On Wed, 2009-11-25 at 11:47 -0500, Stephen Bannasch wrote: I'n new at using hg ... when I ran hg fpull -u in the root of my bsd-port dir many directories report as unchanged but these three reported that they were skipped: [hotspot] skipped: 'hotspot' has mq patches applied [jdk] skipped: 'jdk' has mq patches applied [langtools] skipped: 'langtools' has mq patches applied It seems like the current state of my repo is blocking needed updates. Right. I normally pop all patches manually: $ cd hotspot $ hg qpop -a ... What are the mq patches? The mercurial queues (hotspot, jdk, langtools) contain all mlvm patches required. What's the best way to bring my local hg repos back to a state where hg fpull -u will pull in and apply the patches I need? See above. -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
[tools-compilers] where is Sun Studio connecting to?
On Thu, 2009-11-19 at 13:21 -0800, Kuldip Oberoi wrote: Correct. Here's more info: http://wikis.sun.com/display/SunStudio/Sun+Studio+FAQ#SunStudioFAQ-GeneralWhyarethetoolssendingpacketsoremailsoutsidemysite%21 Thanks. It looks like setting both variables make it work. -- Christian
[tools-compilers] where is Sun Studio connecting to?
On Wed, 2009-11-18 at 16:55 +0300, Maxim Kartashev wrote: In brief, Sun Studio is reporting its usage back to Sun; this feature can be turned off. I think you find all answers here: http://developers.sun.com/sunstudio/downloads/ssx/express_May2008_readme.html#4 Wow! That's more than I expect a compiler should do. I tried to disable it but it didn't work (in bash): $ export UT_NO_USAGE_TRACKING=1 $ CC foo.cpp hang ^C $ CC -V CC: Sun C++ 5.9 SunOS_i386 2007/05/03 -- Christian
[laptop-discuss] resume time
On Tue, 2009-11-17 at 15:48 -0500, Albert Lee wrote: Then on the installed system do: # update_drv -a -i 'pci10de,ab5' ahci; touch /reconfigure The driver will fail to attach but that's expected. Can I do that on my running system and reboot to get the ahci driver to be used instead of the pci-ata one? -- Christian
[laptop-discuss] resume time
On Tue, 2009-10-27 at 12:06 -0700, Garrett D'Amore wrote: Sounds like you have a problem, then. Note that I prefer to test with uadmin 3 20, because this includes the actual power cycle (but then you need to press the power button to turn it back on.) But if uadmin 3 20 works, and uadmin 3 22 doesn't, then that's a bug too! (Because we might have to roll back from a failed suspend attempt, i.e. we might not actually enter S3 state.) Finally I found some time to try a uadmin 3 20 (on snv_126) and it does a successful suspend/resume cycle, but it takes the same amount of time. -- Christian
Re: mlvm don't build
On Mon, 2009-11-16 at 11:03 +0100, Raffaello Giulietti wrote: But currently the patch queue is not in a state that allow to play with it, because method handle and indy patchs are in the review process in order to be integrated in hotspot main workspace. I think we have to wait the end of the sync with the main workspace before to be able to play again with indy patches. Rémi I see. So, let's wait for more stable changesets. I hope we get them in soon. But I will have a look at the indy.patch problem. -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [indiana-discuss] OpenSolaris package repository update, development build 127, x86/x64/SPARC (15 new packages)
On Fri, 2009-11-13 at 18:21 -0800, david.co...@sun.com wrote: The OpenSolaris development package repository http://pkg.opensolaris.org/dev/ has been updated to reflect the changes up to and including snv_127 for both x86/x64 and SPARC platforms. This update includes fixes to the Caiman Slim Install and the Image Packaging System (IPS). Did something change with font rendering? The hinting is completely different and I have to turn it *off* to get similar fonts as on snv_126. -- Christian ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
Re: [indiana-discuss] OpenSolaris package repository update, development build 127, x86/x64/SPARC (15 new packages)
On Sun, 2009-11-15 at 07:57 -0500, Sebastien Roy wrote: On Sun, 2009-11-15 at 12:30 +0100, Christian Thalinger wrote: On Fri, 2009-11-13 at 18:21 -0800, david.co...@sun.com wrote: The OpenSolaris development package repository http://pkg.opensolaris.org/dev/ has been updated to reflect the changes up to and including snv_127 for both x86/x64 and SPARC platforms. This update includes fixes to the Caiman Slim Install and the Image Packaging System (IPS). Did something change with font rendering? The hinting is completely different and I have to turn it *off* to get similar fonts as on snv_126. I saw this and reported it. The folks responsible for fonts are looking into it (I don't have a bug filed yet). Ahh, thanks. -- Christian ___ indiana-discuss mailing list indiana-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
[laptop-discuss] [xwin-discuss] page up/down, home/end on Macbook Pro
On Wed, 2009-10-28 at 21:04 +0100, Christian Thalinger wrote: On Wed, 2009-10-28 at 15:59 -0400, John Martin wrote: The X server does see something as keypress does take down the cursor in a gnome-terminal window and briefly passes the flashing cursor. Both of these are normal behavior for a keypress. Interesting. I just tried that and it happens e.g. with the shift key but not with the fn key. ...and a blank laptop screen does not wake up when I press the fn key which makes it obvious that the keycode is not passed to the X server. -- Christian
[xwin-discuss] [laptop-discuss] page up/down, home/end on Macbook Pro
On Wed, 2009-10-28 at 21:04 +0100, Christian Thalinger wrote: On Wed, 2009-10-28 at 15:59 -0400, John Martin wrote: The X server does see something as keypress does take down the cursor in a gnome-terminal window and briefly passes the flashing cursor. Both of these are normal behavior for a keypress. Interesting. I just tried that and it happens e.g. with the shift key but not with the fn key. ...and a blank laptop screen does not wake up when I press the fn key which makes it obvious that the keycode is not passed to the X server. -- Christian
Re: Rebuilding rt.jar
On Wed, 2009-11-04 at 02:14 -0800, alan yung wrote: If I want to re-generate rt.jar file in j2sdk image, where should i build? For instance, if I change something in java/dyn/, building in jdk/make/java/dyn doesn't seem to regenerate rt.jar file, thus the change doesn't take effect. What do I do to regenerate rt.jar? Hmm, I don't know if there is a target for it (I guess not a trivial one, you could ask on core-libs-dev or build-dev) but simply removing rt-orig.jar from tmp/ in the build directory should do the job. -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
[xwin-discuss] [laptop-discuss] page up/down, home/end on Macbook Pro
On Wed, 2009-10-28 at 15:59 -0400, John Martin wrote: The X server does see something as keypress does take down the cursor in a gnome-terminal window and briefly passes the flashing cursor. Both of these are normal behavior for a keypress. Interesting. I just tried that and it happens e.g. with the shift key but not with the fn key. -- Christian
[laptop-discuss] resume time
On Fri, 2009-10-23 at 22:50 +0200, Christian Thalinger wrote: On Fri, 2009-10-23 at 12:41 -0700, Randy Fishel wrote: On Fri, 23 Oct 2009, Christian Thalinger wrote: Very odd is the time it takes for my MacBook Pro to resume: 72 seconds! Does anyone here have a similar problem? Or maybe someone with a MacBook Pro that resumes faster? -- Christian Is this a MacBook Pro running Solaris or OpenSolaris? If so, what build? It's OpenSolaris build 111b, but it also happens with 124 and 125. Anyone else seeing a similar problem? Or is resume time for everybody down at 1 second? -- Christian
[laptop-discuss] resume time
On Tue, 2009-10-27 at 16:46 +0100, Juergen Keil wrote: 2009/10/27 Christian Thalinger Christian.Thalinger at sun.com: On Fri, 2009-10-23 at 22:50 +0200, Christian Thalinger wrote: It's OpenSolaris build 111b, but it also happens with 124 and 125. Anyone else seeing a similar problem? Or is resume time for everybody down at 1 second? I have two boxes that are able to suspend / resume, and both resume in ~ 3 - 4 seconds. Hmm, I wonder where I lose the time...
hg: mlvm/mlvm/hotspot: indy.compiler.inline: Changed oops to handles to be GC safe.
Changeset: 5972cb463866 Author:twisti Date: 2009-10-27 16:03 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/5972cb463866 indy.compiler.inline: Changed oops to handles to be GC safe. ! indy.compiler.inline.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
[laptop-discuss] Monitor Won't Wake After Power Save
On Fri, 2009-10-23 at 04:54 -0700, J. Adam Craig wrote: Hello! Having some trouble with my computer not waking the monitor after it enters power save mode, presumably triggered by Display Power Management. Troubleshot by going to System Preferences Screensaver Advanced and then unchecking the option for Power Management Enabled under the Display Power Management heading. With the option unchecked, the monitor stays on and I can resume working when I need to. If I re-enable, then monitor goes into power save mode again and the system is unresponsive to mouse and keyboard. Any help would be greatly appreciated, as I like the idea of saving electricity by letting my monitor go into standby. OpenSolaris is great! Thanks for all your hard work. I've filed: http://defect.opensolaris.org/bz/show_bug.cgi?id=11719 That's one of the bugs why I can't use svn_125 and I'm still on 111b. -- Christian
[laptop-discuss] resume time
Very odd is the time it takes for my MacBook Pro to resume: 72 seconds! Does anyone here have a similar problem? Or maybe someone with a MacBook Pro that resumes faster? -- Christian
[laptop-discuss] resume time
On Fri, 2009-10-23 at 12:41 -0700, Randy Fishel wrote: On Fri, 23 Oct 2009, Christian Thalinger wrote: Very odd is the time it takes for my MacBook Pro to resume: 72 seconds! Does anyone here have a similar problem? Or maybe someone with a MacBook Pro that resumes faster? -- Christian Is this a MacBook Pro running Solaris or OpenSolaris? If so, what build? It's OpenSolaris build 111b, but it also happens with 124 and 125. -- Christian
Re: hotspot build failure on ubuntu x86_64
On Fri, 2009-10-23 at 14:32 +0800, Weijun Wang wrote: Hi Martin Since the error line is only a printf message, I just remove the line. And now everything builds fine! I'll see if the PTR_FORMAT macro is used in other places and why there's no problem there. This line is part of the new JSR 292 code and a fix for the build issue will be commited (with all other JSR 292 stuff) before M5. Sorry for the inconvenience. -- Christian
hg: mlvm/mlvm/hotspot: indy-amd64: Review changes.
Changeset: b10789e6d957 Author:twisti Date: 2009-10-22 10:55 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/b10789e6d957 indy-amd64: Review changes. ! indy-amd64.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: good platform to build da Vinci on?
On Thu, 2009-10-22 at 11:18 +0200, Raffaello Giulietti wrote: Christian Thalinger wrote: On Thu, 2009-10-22 at 10:56 +0200, Raffaello Giulietti wrote: Yes, all mercurial py modules are there, installed by invoking pkg install SUNWmercurial. None of them, however, is accessed by hg. I suspect the installer fails to setup something in the environment to make python aware of the vendor-packages folder. Sorry, I don't know. I only installed the SUNWmercurial package and it worked. Something strange in your .hgrc? Christian, my .hgrc is exactly as recommended by the mlvm doc. I'll ask some knowledgeable python guy about how to configure it to access the vendor-packages dir. Btw. did you try to specify the mq.py file, like I do for the forest extension: forest = ~/.hgext/hgforest/forest.py -- Christian ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: series: Make dynopt.patch -buildable for now.
Changeset: 64568693be14 Author:twisti Date: 2009-10-22 11:33 +0200 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/64568693be14 series: Make dynopt.patch -buildable for now. ! series ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
[laptop-discuss] [xwin-discuss] page up/down, home/end on Macbook Pro
On Wed, 2009-10-21 at 07:26 -0700, Alan Coopersmith wrote: Christian Thalinger wrote: On Tue, 2009-10-20 at 18:27 +0200, Christian Thalinger wrote: Does anyone know what keyboard type I could use to get page up/down and home/end keys (in combination with fn) working? It seems that the fn key keycode is too big for X: http://damienciabrini.blogspot.com/2009/05/make-your-apple-aluminium-keyboard.html Is there any chance that this keycode can be used in Solaris? (Hmm, probably I should send this to xwin-discuss...) First you'd need to get the Solaris kernel keyboard drivers to send it up to X - they normally drop keys they don't support. Uhm... well, I never touched any kernel code. I think I need to find the right mailing list to ask for help. -- Christian
[laptop-discuss] [xwin-discuss] page up/down, home/end on Macbook Pro
On Wed, 2009-10-21 at 13:05 -0700, Alan Coopersmith wrote: Christian Thalinger wrote: On Wed, 2009-10-21 at 12:39 -0700, Alan Coopersmith wrote: John Martin wrote: Do we have a dtrace script that can be run on this notebook to verify the X server is getting keycodes for each key needed in these sequences? Yes - see the description of this bug: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6526932 Should it be the case that I have conskbd and consms? Because I don't... Oh, forgot that had changed since that bug report - if you're using USB devices, they should be /dev/usb/hid* entries now - PS/2 mouse should be /dev/kdmouse I think, not sure about PS/2 keyboard. No, don't have that either. Is it maybe something like this? 31: S_IFCHR mode:0600 dev:313,0 ino:17825828 uid:101 gid:10 rdev:34,16 O_RDONLY|O_NONBLOCK /devices/pci at 0,0/pci10de,cb79 at 6/hub at 1/keyboard at 2:keyboard -- Christian
[laptop-discuss] [xwin-discuss] page up/down, home/end on Macbook Pro
On Wed, 2009-10-21 at 13:21 -0700, Alan Coopersmith wrote: Yes - if you ls -l /dev/usb/hid* you should see those are links to files with names like that, so that humans can type less. OK, it works. Almost all keys produce some output but the fn key does not (almost means: the eject key does not produce an output too). Does that mean the kernel does not forward the key? -- Christian
[laptop-discuss] [xwin-discuss] page up/down, home/end on Macbook Pro
On Wed, 2009-10-21 at 13:43 -0700, Alan Coopersmith wrote: Christian Thalinger wrote: On Wed, 2009-10-21 at 13:35 -0700, Alan Coopersmith wrote: Christian Thalinger wrote: On Wed, 2009-10-21 at 13:21 -0700, Alan Coopersmith wrote: Yes - if you ls -l /dev/usb/hid* you should see those are links to files with names like that, so that humans can type less. OK, it works. Almost all keys produce some output but the fn key does not (almost means: the eject key does not produce an output too). Does that mean the kernel does not forward the key? Yes, if there's no event for the X server to read from the kernel, there's nothing we can do until the kernel driver is modified to send us one. Do you know who I could contact? Sorry, I'm a bit lost... Since it's a USB keyboard, the USB driver team in Beijing would be the ones to do it - I don't know if any of them are on driver-discuss or laptop-discuss. I hope so :-) The bug category to file an RFE in would be solaris/driver/usb-keyboard I will file an RFE tomorrow. Thanks a lot! -- Christian
[xwin-discuss] [laptop-discuss] page up/down, home/end on Macbook Pro
On Wed, 2009-10-21 at 07:26 -0700, Alan Coopersmith wrote: Christian Thalinger wrote: On Tue, 2009-10-20 at 18:27 +0200, Christian Thalinger wrote: Does anyone know what keyboard type I could use to get page up/down and home/end keys (in combination with fn) working? It seems that the fn key keycode is too big for X: http://damienciabrini.blogspot.com/2009/05/make-your-apple-aluminium-keyboard.html Is there any chance that this keycode can be used in Solaris? (Hmm, probably I should send this to xwin-discuss...) First you'd need to get the Solaris kernel keyboard drivers to send it up to X - they normally drop keys they don't support. Uhm... well, I never touched any kernel code. I think I need to find the right mailing list to ask for help. -- Christian
[xwin-discuss] [laptop-discuss] page up/down, home/end on Macbook Pro
On Wed, 2009-10-21 at 12:39 -0700, Alan Coopersmith wrote: John Martin wrote: Do we have a dtrace script that can be run on this notebook to verify the X server is getting keycodes for each key needed in these sequences? Yes - see the description of this bug: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6526932 Should it be the case that I have conskbd and consms? Because I don't... -- Christian
[xwin-discuss] [laptop-discuss] page up/down, home/end on Macbook Pro
On Wed, 2009-10-21 at 13:05 -0700, Alan Coopersmith wrote: Christian Thalinger wrote: On Wed, 2009-10-21 at 12:39 -0700, Alan Coopersmith wrote: John Martin wrote: Do we have a dtrace script that can be run on this notebook to verify the X server is getting keycodes for each key needed in these sequences? Yes - see the description of this bug: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6526932 Should it be the case that I have conskbd and consms? Because I don't... Oh, forgot that had changed since that bug report - if you're using USB devices, they should be /dev/usb/hid* entries now - PS/2 mouse should be /dev/kdmouse I think, not sure about PS/2 keyboard. No, don't have that either. Is it maybe something like this? 31: S_IFCHR mode:0600 dev:313,0 ino:17825828 uid:101 gid:10 rdev:34,16 O_RDONLY|O_NONBLOCK /devices/pci at 0,0/pci10de,cb79 at 6/hub at 1/keyboard at 2:keyboard -- Christian
[xwin-discuss] [laptop-discuss] page up/down, home/end on Macbook Pro
On Wed, 2009-10-21 at 13:21 -0700, Alan Coopersmith wrote: Yes - if you ls -l /dev/usb/hid* you should see those are links to files with names like that, so that humans can type less. OK, it works. Almost all keys produce some output but the fn key does not (almost means: the eject key does not produce an output too). Does that mean the kernel does not forward the key? -- Christian
[xwin-discuss] [laptop-discuss] page up/down, home/end on Macbook Pro
On Wed, 2009-10-21 at 13:35 -0700, Alan Coopersmith wrote: Christian Thalinger wrote: On Wed, 2009-10-21 at 13:21 -0700, Alan Coopersmith wrote: Yes - if you ls -l /dev/usb/hid* you should see those are links to files with names like that, so that humans can type less. OK, it works. Almost all keys produce some output but the fn key does not (almost means: the eject key does not produce an output too). Does that mean the kernel does not forward the key? Yes, if there's no event for the X server to read from the kernel, there's nothing we can do until the kernel driver is modified to send us one. Do you know who I could contact? Sorry, I'm a bit lost... -- Christian
