Skip to Main Content

Infrastructure Software

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Support for 8-bit pseudocolor visuals on Solaris 10 u8 Virtualbox guest

807559Oct 16 2009 — edited Oct 29 2009
Hello,

I am running Solaris 10 u8 x86 as a Virtualbox (3.0.8) guest on a WinXP host with a NVIDIA Quadro FX 3500 vcard. I use JDS for the Solaris guest, and only 24-bit truecolor visuals are available for the desktop. I desperately need to run Xnest in 8-bit pseudocolor mode for an application. The video driver supplied with the Vbox Solaris guest additions has limited capability, and I think that until that driver is upgraded, I am out of luck. Does anyone have any different thoughts about that?

Is there a way to edit xorg.conf to get support for 8-bit pseudocolor overlay graphics? Wouldchanging the video driver in that file from vboxvideo to either VGA or VESA help? Any advice from an X expert would be GREATLY appreciated.

I've also tried to use svcadm to get the guest to open in 8-bit mode (default depth), but I think that the Vbox video driver (standard and VESA) only support 16- and 32-bit color modes. Is there some other way to get JDS or CDE in the guest to run in 8-bit color?

Thanks.....

Comments

Erik - Hotspot Engineer-Oracle
Answer

1) Yes, using the maxage parameter. But it only works if disk=true, if you have a disk repository, If you don't specify maxage/maxsize, and only set disk=true, the JVM will set up default values, if you use defaultrecording=true. If you want infinite, set maxsize=0,maxage=0 to overide the defaults.

2) The maxage/maxsize parameters are thresholds at which the JVM will start to remove recording chunks from the disk repository. Since it would be to expensive to check thresholds at every event written, the thresholds are only checked when a new recording chunk is created, which happens about every 12-15 Mb  (depending on how much data exist in thread buffers when they are flushed)  So with a  short maxage, like 1 minute, there may not have been enough data to trigger removal of chunks.

Marked as Answer by ctoomey · Sep 27 2020
ctoomey

Thanks Erik, adding disk=true did the trick.

I've found that the documentation and functionality of the -XX:StartFlightRecording and -XX:FlightRecorderOptions is very unclear and confusing.  Can you or others comment/clarify the following?


  • Is it correct that the XX:StartFlightRecording options are meant to only apply to a special start recording (that starts at server start time), while the XX:FlightRecorderOptions are meant to apply to any/all recordings?
  • Why are some of the XX:FlightRecorderOptions not also available for XX:StartFlightRecording, e.g., disk=true, dumponexit=true?  This makes it tricky to configure the start recording as you need to specify different options with different XX: parameters.
  • The settings=path option seems to have no effect when given to XX:FlightRecorderOptions, even though it's listed in the documentation page above as being a supported option.  When I use settings=path with XX:FlightRecorderOptions, I still get the default settings.  Is this a known implementation or documentation bug?
  • With both XX:StartFlightRecording and XX:FlightRecorderOptions, what's the behavior when defaultrecording=false?  The documentation says "Specifies whether the recording is a continuous background recording or it runs for a limited time. By default, this parameter is set to false (recording runs for a limited time)."  What is this limited time (how long)?  And is it a limited time forward from the beginning, or backwards from the current time?  Why is this setting even needed given the maxage, maxsize, and duration settings?

thanks,

Chris

Erik - Hotspot Engineer-Oracle

"Is it correct that the XX:StartFlightRecording options are meant to only apply to a special start recording (that starts at server start time), while the XX:FlightRecorderOptions are meant to apply to any/all recordings"


-XX:FlightRecorderOptions is meant to configure global settings, but there are also options that controls the default in-memory recording (called "Hotspot default"), which can be turned on by setting defaultrecording=true. Since Flight Recorder records the union of all ongoing recordings, it will in practise apply to other recordings as well.

"The settings=path option seems to have no effect when given to XX:FlightRecorderOptions, even though it's listed in the documentation page above as being a supported option.  When I use settings=path with XX:FlightRecorderOptions, I still get the default settings.  Is this a known implementation or documentation bug?"


It's a known bug, as a workaround you can replace the file named default.jfc in JRE_HOME/lib/jfr with the settings file you want, i.e profile.jfc

"With both XX:StartFlightRecording and XX:FlightRecorderOptions, what's the behavior when defaultrecording=false?  "


No default (in-memory) recording will be started

"The documentation says "Specifies whether the recording is a continuous background recording or it runs for a limited time. By default, this parameter is set to false (recording runs for a limited time)." What is this limited time (how long)?  And is it a limited time forward from the beginning, or backwards from the current time?  Why is this setting even needed given the maxage, maxsize, and duration settings?"


It's incorrect, defaultrecording=true is just a convenience option for starting the default in-memory recording. There is no limit put in place if you set it to false.

If you want to use a disk repository, you can ignore all options that includes the word "default" and just use -XX:StartFlightRecording.

ctoomey

Thanks Erik.

If you want to use a disk repository, you can ignore all options that includes the word "default" and just use -XX:StartFlightRecording.

I found that even when I use -XX:StartFlightRecording, I can only get that recording dumped to disk on exit if I set defaultrecording=true along with disk=true,dumponexit=true,dumponexitpath=path via -XX:FlightRecorderOptions .

Chris

ctoomey wrote:

Thanks Erik.

If you want to use a disk repository, you can ignore all options that includes the word "default" and just use -XX:StartFlightRecording.

I found that even when I use -XX:StartFlightRecording, I can only get that recording dumped to disk on exit if I set defaultrecording=true along with disk=true,dumponexit=true,dumponexitpath=path via -XX:FlightRecorderOptions .

Chris

You should be able dump the buffers on exit, even if you haven't started a defaultrecording.

I will file a bug report. Thanks for reporting.

1 - 5
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Nov 26 2009
Added on Oct 16 2009
17 comments
749 views